index.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>lowRISC: Collaborative open silicon engineering</title><link>https://www.lowrisc.org/</link><description>Recent blog posts from lowRISC</description><language>en-us</language><lastBuildDate>Wed, 05 Feb 2020 15:12:36 +0000</lastBuildDate><atom:link type="application/rss+xml" href="https://www.lowrisc.org/index.xml" rel="self"/><copyright> The text content on this website is licensed under a Creative Commons Attribution 4.0 International License, except where otherwise noted. No license is granted for logos or other trademarks. Other content Copyright lowRISC Contributors.</copyright><item><title>At FOSDEM you can hear how we made our Ibex CPU core faster</title><link>https://www.lowrisc.org/blog/2020/01/at-fosdem-you-can-hear-how-we-made-our-ibex-cpu-core-faster/</link><guid>https://www.lowrisc.org/blog/2020/01/at-fosdem-you-can-hear-how-we-made-our-ibex-cpu-core-faster/</guid><pubDate>Wed, 29 Jan 2020 15:00:00 +0000</pubDate><author>info@lowrisc.org (Greg Chadwick)</author><description><![CDATA[ 









  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2020/01/at-fosdem-you-can-hear-how-we-made-our-ibex-cpu-core-faster/FOSDEM_logo_huf82e281a9237d835c6322add1947ed2b_9557_200x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2020/01/at-fosdem-you-can-hear-how-we-made-our-ibex-cpu-core-faster/FOSDEM_logo_huf82e281a9237d835c6322add1947ed2b_9557_400x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2020/01/at-fosdem-you-can-hear-how-we-made-our-ibex-cpu-core-faster/FOSDEM_logo_huf82e281a9237d835c6322add1947ed2b_9557_200x0_resize_box_2.png"alt='FOSDEM logo' title='FOSDEM' class='float-right m-2 '
  >





<p>I’ll be giving a talk in the <a href="https://fosdem.org/2020/schedule/track/risc_v/">RISC-V devroom</a> at FOSDEM on Saturday 1st February, in which I’ll describe how we are analysing and improving the performance of the <a href="https://github.com/lowRISC/ibex">Ibex RISC-V CPU core</a>. I’ll discuss how Verilator is used to simulate Ibex running CoreMark and Embench and how I’ve analysed these simulations to identify major sources of stalls. This is used to inform what improvements should be made. Yosys was used to analyse the impact on area and clock frequency from these changes. I’ll talk about how this analysis was performed and what was required to avoid adversely impacting clock frequency.</p>

<p><em>Update: talk <a href="https://fosdem.org/2020/schedule/event/riscv_lowrisc/attachments/slides/3689/export/events/attachments/riscv_lowrisc/slides/3689/20200201_FOSDEM_Ibex_Perf.pdf">slides</a> and <a href="https://ftp.fau.de/fosdem/2020/K.3.401/riscv_lowrisc.mp4">video</a> are now available.</em></p>
 ]]></description></item><item><title>lowRISC 101: Introduction to lowRISC at the RISC-V Summit</title><link>https://www.lowrisc.org/blog/2019/12/lowrisc-101-introduction-to-lowrisc-at-the-risc-v-summit/</link><guid>https://www.lowrisc.org/blog/2019/12/lowrisc-101-introduction-to-lowrisc-at-the-risc-v-summit/</guid><pubDate>Thu, 05 Dec 2019 09:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>With the <a href="https://www.lowrisc.org/blog/2019/11/announcing-opentitan-the-first-transparent-silicon-root-of-trust/">recent announcement of OpenTitan</a>, we at lowRISC had many great conversations about the work we do to produce high-quality open source hardware and software.
A great place to continue these discussions is the <a href="https://tmt.knect365.com/risc-v-summit/">RISC-V Summit in San Jose, CA</a> (Dec 10 - 12, 2019).
lowRISC will showcase its work in the conference track and in the exhibit hall.</p>

<p>At booth 101, lowRISC will showcase its recent work and our engineers will be around to answer your questions.
Stop by if you have questions about OpenTitan, lowRISC in general, or about the LLVM compiler work we&rsquo;re doing!</p>

<p>If you&rsquo;re using the LLVM compiler or are planning to use it for your next RISC-V project, we invite you to join Alex&rsquo;s talk in the conference track.
Titled &ldquo;Production-ready RISC-V Support in LLVM/Clang 9.0 - How we Got There and What&rsquo;s Next&rdquo; the talk will retrace the journey to make the RISC-V LLVM backend production ready, an effort which hit a major milestone in August this year, when the RISC-V backend was enabled by default for all LLVM/Clang compiler builds.</p>

<p>See you there! And as always, if you cannot make it to the RISC-V Summit, just drop us a line at <a href="mailto:info@lowrisc.org">info@lowrisc.org</a>!</p>

<p><strong>Quick facts</strong></p>

<ul>
<li><a href="https://tmt.knect365.com/risc-v-summit/agenda/2#software_production-ready-risc-v-support-in-llvmclang-90-how-we-got-there-and-whats-next">Production-ready RISC-V Support in LLVM/Clang 9.0 - How we Got There and What&rsquo;s Next</a>. Wednesday, 11 December 2019 1:20pm - 1:40pm, Grand Ballroom 220-C</li>
<li>Find lowRISC in booth 101 in the exhibit hall.</li>
</ul>
 ]]></description></item><item><title>Get started with OpenTitan</title><link>https://www.lowrisc.org/blog/2019/11/get-started-with-opentitan/</link><guid>https://www.lowrisc.org/blog/2019/11/get-started-with-opentitan/</guid><pubDate>Tue, 26 Nov 2019 09:00:00 +0000</pubDate><author>info@lowrisc.org (Greg Chadwick)</author><description><![CDATA[ <p>Interested in trying out the recently announced OpenTitan? We&rsquo;ve put together a
video that goes through an overview of how the OpenTitan prototype system is
put together and how to get up and running with our pre-built release
(providing simulator binaries and pre-built FPGA images for the Nexys Video
Artix-7 board). It follows the steps from the <a href="https://docs.opentitan.org/doc/ug/quickstart/">OpenTitan Quickstart
Guide</a>.</p>

<p>You can find out more about OpenTitan from our <a href="https://www.lowrisc.org/blog/2019/11/announcing-opentitan-the-first-transparent-silicon-root-of-trust/">announcement blog</a> and the <a href="https://www.opentitan.org">OpenTitan
website</a>.</p>

<div class="embed-responsive embed-responsive-16by9">
  <iframe class="embed-responsive-item" src="https://www.youtube.com/embed/fczdna1Thks" allowfullscreen></iframe>
</div>
 ]]></description></item><item><title>Announcing OpenTitan, the First Transparent Silicon Root of Trust</title><link>https://www.lowrisc.org/blog/2019/11/announcing-opentitan-the-first-transparent-silicon-root-of-trust/</link><guid>https://www.lowrisc.org/blog/2019/11/announcing-opentitan-the-first-transparent-silicon-root-of-trust/</guid><pubDate>Tue, 05 Nov 2019 14:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>Today, we are excited to unveil the <a href="https://opentitan.org">OpenTitan</a> silicon root of trust (RoT) project, a new effort built using the successful collaborative engineering model created by lowRISC in partnership with Google and other commercial and academic partners.</p>

<p>This effort sets a new bar for transparency in trusted silicon, and lowRISC is proud to serve as both steward and not-for-profit engineering contributor to OpenTitan, the world’s first <em>open source</em> silicon RoT.</p>

<p>Silicon root of trust chips increase trust in the integrity of the infrastructure on which software runs. They can be used in a variety of devices: server motherboards, network cards, laptops, phones, consumer routers, IoT devices, and more. Potential security benefits from a silicon root of trust include:</p>

<ul>
<li>Establishing trust at the lowest level in the system - the silicon; independent of the main processor and operating system.</li>
<li>Leveraging a secure foundation to ensure the integrity of the lowest level mutable firmware of the device.</li>
<li>Giving the device a cryptographically strong identity. For example, this enables a datacenter control plane to verify provenance before a new machine is admitted into the fleet.</li>
<li>Enabling secure storage, including physical attack resistance (e.g., a server in a third-party datacenter or moving through the supply chain).</li>
<li>Providing tamper-evident logging, integrity measurements, integrated universal 2<sup>nd</sup>-factor devices, and other security services.</li>
</ul>

<p><em>Open sourcing</em> the silicon design makes it more transparent, trustworthy, and ultimately, secure.</p>











<img
  src="https://www.lowrisc.org/blog/2019/11/announcing-opentitan-the-first-transparent-silicon-root-of-trust/logo-opentitan.svg"
  alt='OpenTitan' 
  title='OpenTitan' 
  width='400'
  class='float-right rounded m-2 '
>





<p>The OpenTitan project follows three core design principles:</p>

<ul>
<li><strong>Transparency</strong>  &ndash; anyone can inspect, evaluate, and contribute to OpenTitan’s design, firmware and documentation, helping to build more auditable, trustworthy silicon root of trust chips for all.</li>
<li><strong>High quality</strong> &ndash; we are building a high quality, logically secure silicon design, with rigorous design validation and testing, plus reference firmware and technical documentation.</li>
<li><strong>Flexibility</strong> &ndash; OpenTitan adopters can reduce costs and reach more customers by leveraging its vendor-, platform- and policy-agnostic design.</li>
</ul>

<p>The OpenTitan project is stewarded by lowRISC and is a partnership with <a href="https://security.googleblog.com/2019/11/opentitan-open-sourcing-transparent.html">Google</a>, <a href="https://ethz.ch/">ETH Zürich</a>, <a href="https://www.gi-de.com/">G+D Mobile Security</a>, <a href="http://www.nuvoton.com/hq/about-nuvoton/news/products-technology/Nuvoton-Technology-announces-its-collaboration-on-OpenTitan-the-first-open-source-silicon-root-of-trust-RoT-project/?__locale=en">Nuvoton Technology</a> and <a href="https://www.westerndigital.com/">Western Digital</a>.
Engineers from this coalition bring ideas and expertise from many perspectives, and have been working together for more than 18 months on <a href="http://github.com/lowrisc/opentitan">hardware, software and tooling</a> for OpenTitan.
Today, at the mid-point of the project, we’re opening up the <a href="https://github.com/lowRISC/opentitan/">GitHub repository</a> containing this work, so others can get involved!</p>

<p>Compared to existing proprietary silicon RoT systems, OpenTitan represents a radical level of transparency, where virtually everything that can be opened (up to the “foundry boundary”), has been opened:</p>









  <figure class='figured-block text-center'>



<img
  src="https://www.lowrisc.org/blog/2019/11/announcing-opentitan-the-first-transparent-silicon-root-of-trust/opentitan-rot-comparison.svg"
  alt='Traditional RoT vs. OpenTitan' 
  title='Traditional RoT vs. OpenTitan' 
  width='500'
  class='figure-img '
>



    <figcaption class="figure-caption">Traditional RoT vs. OpenTitan</figcaption>
  </figure>



<p>The project is very much a networked collaboration and maintains strong links with engineering teams at our partners.
We are delighted to welcome the broader community now that the founding partnership and principles of OpenTitan are established.</p>

<p>From day one, lowRISC has sought to bring the benefits of open source software to the hardware world.</p>

<p>Benefits to transparency and security from open source silicon include:</p>

<ul>
<li>Enhancing trust and security through design and implementation visibility. Issues can be discovered early, and the need for trust in opaque technologies is reduced.</li>
<li>Enabling and encouraging innovation with modifiable shared components.</li>
<li>Sharing open infrastructure technology permits focus on product differentiation, with shared costs and substantially reduced overall risk.</li>
<li>Saving engineering time, energy and confusion as the reference design implementation <strong>is</strong> the specification.</li>
</ul>

<p>The OpenTitan silicon root of trust is based around our open source Ibex RISC-V processor core, and adds cryptographic coprocessors, a sophisticated key hierarchy, memory hierarchies for volatile and non-volatile storage, IO peripherals, secure boot, and more.
The Ibex processor design was originally developed by ETH Zürich as zero-riscy, then contributed to lowRISC where it has seen substantial further development.</p>

<h2 id="opentitan-the-future-of-collaborative-open-source-silicon-design:56cb3fecc2afbc926c922a40e803922b">OpenTitan: The Future of Collaborative Open Source Silicon Design</h2>

<p>At lowRISC, we view OpenTitan as the ideal test case for our collaborative open source silicon development methodology, creating not just a logically secure design, but also a library of well-structured and reusable IP components, and tools for shared working across the ecosystem too. And while it is the first design to be built in this way, it won’t be the last, as we envisage the use of these same principles, collaboration methodologies and flow in future open silicon design projects of similar and greater magnitude and impact, across many different application domains.</p>

<p>Dominic Rizzo, OpenTitan Lead at Google and our OpenTitan Project Director, has said, “Customers are asked to put faith in proprietary root of trust chips for mission-critical systems without the ability to fully understand, inspect and therefore trust them. By creating OpenTitan with the broader hardware and academic community, we leverage the experience and security principles used to create Google’s Titan chips to make hardware root of trust designs more transparent, inspectable, and accessible to the rest of the industry. Security should never be built on opacity.”</p>

<p>We could not agree more and view OpenTitan as a perfect application for open source silicon.</p>

<p>We welcome new collaborators who want to help make secure open source silicon a reality to check out our work so far in the <a href="https://github.com/lowRISC/opentitan/">GitHub repository</a>, join the <a href="https://www.lowrisc.org/community/">community</a> or <a href="mailto:get-involved@opentitan.org">contact us</a> directly if your organisation would like to get involved. If you are interested in potentially integrating the OpenTitan RoT reference design into your device, <a href="mailto:pilots@opentitan.org">let us know</a>.</p>

<p>Finally, we’re humbled by the support we have received in bringing <a href="https://opentitan.org">OpenTitan</a> to fruition and deeply grateful to our employees, partners and contributors whose efforts are helping make open source secure silicon a reality.</p>

<hr />

<p><em>Alex Bradbury, lowRISC CTO and Co-Founder</em><br>
<em>Professor Andy Hopper, lowRISC Independent Chair</em></p>
 ]]></description></item><item><title>lowRISC Collaborates with Industry Leaders to Create OpenTitan</title><link>https://www.lowrisc.org/blog/2019/11/lowrisc-collaborates-with-industry-leaders-to-create-opentitan/</link><guid>https://www.lowrisc.org/blog/2019/11/lowrisc-collaborates-with-industry-leaders-to-create-opentitan/</guid><pubDate>Tue, 05 Nov 2019 13:59:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p class="lead">Organisations aim to make the hardware root more transparent, trustworthy, and secure for everyone.</p>

<p>CAMBRIDGE, England&ndash;(BUSINESS WIRE)&ndash;lowRISC C.I.C., the open source silicon and tools collaborative engineering company, today announced that it has partnered with ETH Zürich, Google, G+D Mobile Security, Nuvoton Technology and Western Digital in support of OpenTitan, an open source hardware root of trust (RoT) reference design and integration guidelines that enable chip producers and platform providers to build transparently implemented, high-quality hardware RoT chips tailored for data center servers and other devices.</p>

<p>Security begins with infrastructure, and OpenTitan will help ensure root of trust in hardware, transparently implemented, at the foundation for a multitude of devices such as server motherboards, network cards, routers and IoT. Adopters of this framework can inspect and contribute to OpenTitan’s register-transfer level (RTL) design, firmware, and documentation, helping to build more transparent, trustworthy hardware RoT chips for everyone.</p>

<p>OpenTitan is stewarded by lowRISC, which provides a neutral home for collaborative engineering to develop and maintain open source silicon designs and tools for the long term. As with open source software, open silicon provides a deep level of transparency and therefore auditability, as well as enabling innovation. Shared open infrastructure technology permits focus on product differentiation, with shared costs and substantially reduced overall risk.</p>

<p>The Ibex RISC-V processor core, which was originally developed by ETH Zürich as zero-riscy and contributed to lowRISC earlier this year, forms a key component for OpenTitan. lowRISC is committed to raising the bar for quality in open silicon via a methodical approach that combines the development and use of best practices and coding standards, with rigorous testing and verification.
Key benefits of OpenTitan for chip manufacturers and platform providers include:</p>

<ol>
<li><p><strong>Transparent:</strong> Adopters can inspect and contribute to OpenTitan’s design, firmware, and documentation, helping to build more transparent, trustworthy hardware RoT chips that benefit everyone.</p></li>

<li><p><strong>High-quality:</strong> OpenTitan’s goal is to build and maintain a high-quality and logically secure RTL design, firmware, and documentation. The project is staffed by expert engineers focused on rigorous design validation and technical documentation, all based on key learnings from designing Google’s Titan chips.</p></li>

<li><p><strong>Flexible:</strong> Adopters can increase their total addressable market and reduce costs by using a single platform-agnostic hardware RoT design that can be integrated in data center servers, peripherals, and any other hardware platforms.</p></li>
</ol>

<p>“We believe collaboratively developed open source silicon designs provide the flexible, cost effective base needed for future generations of secure hardware products,” said Alex Bradbury, lowRISC CTO. “The lowRISC not-for-profit structure combined with full stack engineering capabilities in-house, enables us to manage high quality projects like OpenTitan, and we look forward to developing this partnership and new ones in the future.”</p>

<p>“At lowRISC, our mission is to establish a vibrant ecosystem around open silicon designs and to help lower the barrier to producing custom chips,” said Gavin Ferris, lowRISC CIC board member. “Creating an ecosystem of like-minded organizations focused on the goal of improving transparency around chips helps increase trust in the overall security of the infrastructure on which software runs. With OpenTitan, enterprise organizations and consumers alike will benefit from services built on a more secure infrastructure that is anchored in transparently implemented OpenTitan chips.”</p>

<p>“Customers are asked to put faith in proprietary hardware RoT chips for their mission-critical systems without the ability to fully understand, inspect and therefore trust them,” said Dominic Rizzo, OpenTitan Lead at Google and lowRISC’s OpenTitan Project Director. “By creating OpenTitan with the broader hardware and academic community, we can leverage the experience and security principles used to create Google’s own Titan chips to make hardware RoT designs more transparent, inspectable, and accessible to the rest of the industry. Security should never be built on opacity.”</p>

<p>Collaboration is fundamental to open silicon and at the core of everything that lowRISC does, bringing to projects a deep understanding of open source licensing, contributor models and community building, and providing a uniquely positioned engineering capability.</p>

<p><strong>About lowRISC</strong></p>

<p>lowRISC C.I.C. is a not-for-profit company that aims to demonstrate, promote and support the use of open-source hardware - bringing the benefits of open-source to the hardware world. We are producing high-quality, security-focused, open, and flexible IP. Our expertise includes the LLVM Compiler, novel hardware security extensions and RISC-V tools, hardware and processor design.</p>

<p><strong>Contacts</strong></p>

<p>Andrew Back<br>
lowRISC<br>
press@lowrisc.org</p>
 ]]></description></item><item><title>Andy Hopper joins lowRISC CIC Board as Independent Chair</title><link>https://www.lowrisc.org/blog/2019/11/andy-hopper-joins-lowrisc-cic-board-as-independent-chair/</link><guid>https://www.lowrisc.org/blog/2019/11/andy-hopper-joins-lowrisc-cic-board-as-independent-chair/</guid><pubDate>Tue, 05 Nov 2019 09:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 









  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/11/andy-hopper-joins-lowrisc-cic-board-as-independent-chair/andy-hopper_hu2c6ee2f3eefab707dfe9b96887be9216_36641_300x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/11/andy-hopper-joins-lowrisc-cic-board-as-independent-chair/andy-hopper_hu2c6ee2f3eefab707dfe9b96887be9216_36641_600x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/11/andy-hopper-joins-lowrisc-cic-board-as-independent-chair/andy-hopper_hu2c6ee2f3eefab707dfe9b96887be9216_36641_300x0_resize_q75_box.jpg"alt='Andy Hopper' title='Andy Hopper' class='float-right rounded m-2 '
  >





<p>Today, we are delighted to announce that <a href="https://www.cl.cam.ac.uk/~ah12/">Professor Andy
Hopper</a>, CBE FRS FIET FREng, has joined the
lowRISC Board of Directors as Independent Chair.</p>

<p>&ldquo;I&rsquo;m delighted to be joining lowRISC CIC,&rdquo; said Prof. Hopper, speaking today
from Cambridge UK, &ldquo;As digital systems pervade every aspect of our lives trust
and transparency become crucial. An open source approach allows for public
inspection of the principles and implementations being used. I believe the
future of digital systems will be underpinned by not for profit organisations
that provide design transparency and enable real innovation. I am putting all
my weight behind lowRISC because it is an indispensable component of our
digital world.&rdquo;</p>

<p>Professor Hopper, Treasurer and Vice-President of the Royal Society and
Professor of Computer Technology at the University of Cambridge, is a pivotal
figure in the UK technology scene. He was the Research Director of Acorn
Computers from 1979-85, during which period the pioneering ARM1 RISC processor
was developed<sup>1</sup>, and headed up the world-renowned Cambridge
University Computer Lab between 2004 and 2018.</p>

<p>Cited as one of the <a href="https://www.timeshighereducation.com/cn/news/the-uks-100-leading-practising-scientists/2010580.article">UK&rsquo;s leading practicing
scientists</a>,
Professor Hopper also has deep connections within the business community,
having co-founded thirteen spin-outs and start-ups, three of which have
subsequently been taken public. In recent years, the companies he helped
create have
<a href="https://en.wikipedia.org/wiki/Queen%27s_Awards_for_Enterprise">received five Queen&rsquo;s Awards for Enterprise</a>.</p>

<p>The lowRISC board looks forward to working with Professor Hopper to grow
lowRISC CIC&rsquo;s engineering and executive team, deepen our relationships with
new and existing partners like Google, and maximize the positive global impact
of open source silicon design in a variety of high value target applications.</p>

<p><sup>1</sup> ARM itself was subsequently spun out in 1990.</p>

<hr />

<p><em>Dr Robert Mullins, lowRISC Director and Co-Founder</em></p>
 ]]></description></item><item><title>Introducing Greg &amp; Tom</title><link>https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/</link><guid>https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/</guid><pubDate>Wed, 23 Oct 2019 10:00:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p><em>Greg Chadwick and Tom Roberts recently joined lowRISC’s growing engineering
team. They’ve both taken some time to share a little about what they’re doing at
lowRISC and what motivated them to join.</em></p>

<h3 id="greg:1b825763c3a94080ec9b06870bbb8106">Greg</h3>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/greg_chadwick_hu271acd46af30c78651fe29de4fce35a9_70921_300x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/greg_chadwick_hu271acd46af30c78651fe29de4fce35a9_70921_600x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/greg_chadwick_hu271acd46af30c78651fe29de4fce35a9_70921_300x0_resize_q75_box.jpg"alt='Greg Chadwick photo' title='Greg Chadwick' class='float-right rounded m-2 '
  >





<p>&ldquo;It’s an exciting time to join the lowRISC team! Our Ibex core provides a solid
foundation and clearly demonstrates the value of open source silicon, which I’m
excited to be working on. My work so far has focused on the performance of Ibex;
whilst it’s not intended as a high performance core there are various things we
can do to improve it without major impact to area or power. I’m experimenting
with these improvements as well as building infrastructure to help profile
program execution. I’ll be writing some blog posts to explain these as the work
progresses. On top of that I’ve been writing some more Ibex documentation to go
into the details of how the pipeline works, you can check it out at
<a href="https://ibex-core.readthedocs.io/en/latest/">https://ibex-core.readthedocs.io/en/latest/</a> .</p>

<p>&ldquo;Before lowRISC I worked at Arm and Broadcom. At Arm I worked as a design
engineer on the memory systems of A-class CPU cores. During my time there I
worked on the Cortex-A55, Cortex-A65AE and Neoverse E1, as well as yet
unannounced products. I was also involved in designing memory system
microarchitecture and analysing performance. At Broadcom I worked on the V3D GPU
(as seen in the Raspberry Pi) where again I was involved in microarchitecture
and performance analysis.</p>

<p>&ldquo;At lowRISC, I am going to utilise my industry experience to help produce high
quality IP. I enjoy the opportunity to work in the open, in a collaborative
fashion and hope we can drive the industry forward with new tools and techniques
that might otherwise remain siloed and locked up in closed source companies.</p>

<p>&ldquo;I’m interested in seeing how much of the hardware design process we can open up
at lowRISC. Right now to achieve a high-quality tapeout proprietary tools,
documentation and libraries are required. This contrasts hugely with the
software world where industry leading tools, like GCC and LLVM, and industry
leading software, like the Linux kernel, are open. It’s a massive challenge, but
by developing high quality IP we can help drive forward open silicon tools and
contribute to them ourselves. By sharing our work with great documentation and
writing about how we did it all we can help others follow in our footsteps and
explore new paths.&rdquo;</p>

<h3 id="tom:1b825763c3a94080ec9b06870bbb8106">Tom</h3>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/tom_roberts_hu10017820887ca8c79b6f19390fe9b36c_79142_300x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/tom_roberts_hu10017820887ca8c79b6f19390fe9b36c_79142_600x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/10/introducing-greg-tom/tom_roberts_hu10017820887ca8c79b6f19390fe9b36c_79142_300x0_resize_q75_box.jpg"alt='Tom Roberts photo' title='Tom Roberts' class='float-right rounded m-2 '
  >





<p>&ldquo;Now is a very exciting time to be involved in open source silicon, and lowRISC
is at the heart of it. Change is coming to the industry as a whole, not just to
silicon IP, but from EDA tools all the way to fabrication. I joined lowRISC to
be part of the changes, and to help shape the future of the semiconductor
industry.</p>

<p>&ldquo;Prior to joining lowRISC, I worked at Arm in various CPU design and
verification roles. There I gained experience of high-quality low-power design
and industry leading design verification techniques. In my time at Arm I
contributed to various CPU products, including Cortex-R7, Cortex-M7, Cortex-A53,
Cortex-A65AE, Cortex-A55 and other as-yet unannounced designs.</p>

<p>&ldquo;Since joining lowRISC in August I have been working on improving the Ibex CPU
as well as investigating new approaches to design verification. I am looking
forward to what the future holds!&rdquo;</p>

<hr />

<p>We’re thrilled to have Greg and Tom onboard to help propel our open source
hardware efforts forward. We have a number of open job openings - take a look at
our  <a href="https://www.lowrisc.org/jobs/">jobs page</a> to find out more.</p>

<p><em>Alex Bradbury, CTO and Co-Founder</em></p>
 ]]></description></item><item><title>Ibex on FPGA - Get stuff executed</title><link>https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/</link><guid>https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/</guid><pubDate>Tue, 08 Oct 2019 16:30:00 +0100</pubDate><author>info@lowrisc.org (Pirmin Vogel)</author><description><![CDATA[ 

<p>Our microcontroller-class RISC-V processor core
<a href="https://github.com/lowRISC/ibex/">Ibex</a> for sure is a solid base with which to
start your own project. Over the past months, we have invested a lot of effort
in making the design more mature. This includes <a href="https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/">refactoring the RTL to make the
design more understandable and programmer
friendly</a>,
adding UVM-based verification to the source tree, but also integrating support
for the RISC-V compliance suite and <a href="https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/">enabling publicly visible, open-source
powered continuous integration
(CI)</a> to keep
the design stable.</p>

<p>However, to actually get your own RISC-V system running, quite some more
infrastructure might be needed besides the bare processor core. This includes
for example instruction and data memory, input/outputs, peripherals, interrupt
controllers, a debug module. But don’t worry, we can help you out! There are now
two different system-on-chip designs available to help you get started with Ibex
on FPGA.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/Ibex_on_Nexys_Video_hu5fbae55c836a968bbd3582778db090ca_97378_400x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/Ibex_on_Nexys_Video_hu5fbae55c836a968bbd3582778db090ca_97378_800x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/Ibex_on_Nexys_Video_hu5fbae55c836a968bbd3582778db090ca_97378_400x0_resize_q75_box.jpg"alt='Ibex on the Nexys Video FPGA board' title='Ibex on the Nexys Video FPGA board' class='float-right rounded m-2 '
  >





<h2 id="arty-a7-fpga-example:1e2f11dabcc49400b4a108ba0438a698">Arty A7 FPGA Example</h2>

<p>This is fairly minimal example for the Arty A7 Artix-7 FPGA Development Board
from Digilent that shows you how to integrate Ibex into a top-level design, how
to connect memories and how to compile and run a simple application on the core.
This example is included in the Ibex tree and is a community contribution by
Tobias Wölfel. Thanks @towoe!</p>

<h2 id="pulpissimo:1e2f11dabcc49400b4a108ba0438a698">PULPissimo</h2>

<p><a href="https://github.com/pulp-platform/pulpissimo">PULPissimo</a> is the advanced
microcontroller system from the <a href="https://pulp-platform.org">PULP team</a> at ETH
Zürich. It features a powerful uDMA for an autonomous input/output subsystem
managing peripherals like UART, SPI, I2C and I2S, supports hardware processing
elements, comes with a JTAG debug module and is supported by the <a href="https://github.com/pulp-platform/pulp-sdk">PULP software
development kit (SDK)</a> that comes
with suitable compilers, libraries and even example applications. This complete
ecosystem makes PULPissimo a useful starting point for your own project and
explorations.</p>

<p>Besides re-integrating Ibex into PULPissimo we also created a new FPGA port for
the latest version (Commit ID d37549e). PULPissimo can now be instantiated on
the Digilent Nexys Video Artix-7 FPGA board. This board is equipped with a
XC7A200T device - the largest Artix-7 FPGA supported by the free Vivado WebPACK
Edition - and thus an attractive target for hobbyists.</p>

<p>The picture below visualizes the mapping of the main components inside
PULPissimo onto the resources provided by the Nexys Video FPGA board. Ibex
utilizes a fairly small part of the overall resources (3500 LUTs, roughly 2.6%
of the available resources). There is still plenty of space available for you to
implement you own modules such as custom accelerators!</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/PULPissimo_on_Nexys_Video_hu2ded262682ca1c08237e49774201f555_214568_400x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/PULPissimo_on_Nexys_Video_hu2ded262682ca1c08237e49774201f555_214568_800x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/10/ibex-on-fpga-get-stuff-executed/PULPissimo_on_Nexys_Video_hu2ded262682ca1c08237e49774201f555_214568_400x0_resize_box_2.png"alt='PULPissimo implementation on the Nexys Video FPGA board' title='PULPissimo implementation on the Nexys Video FPGA board' class='rounded m-2 mx-auto d-block '
  >





<p>As you might know, Ibex was originally developed as Zero-riscy at ETH Zürich and
contributed to us in Dec 2018. We are thus even more happy to enable support for
the latest version of Ibex in the PULPissimo system and give something back to
the PULP team!</p>

<h2 id="what-s-next:1e2f11dabcc49400b4a108ba0438a698">What’s next?</h2>

<p>We continue our efforts on making Ibex more robust and extending functionality.
We recently added support for Physical Memory Protection and U-mode. This
will make Ibex a good candidate for porting embedded and real-time operating
systems.</p>

<p><em>Pirmin Vogel</em></p>
 ]]></description></item><item><title>Ibex: Code with Confidence</title><link>https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/</link><guid>https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/</guid><pubDate>Fri, 23 Aug 2019 16:00:00 +0100</pubDate><author>info@lowrisc.org (Philipp Wagner)</author><description><![CDATA[ <p>Ibex, our small RISC-V core, is constantly changing. <a href="https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/">Roughly 50 percent of the
RTL was
refactored</a>
recently! We added features, tests, and cleaned the code up.  We and our
collaborators were able to make these changes (mostly) without breaking Ibex
because we invested in testing: earlier this year we added <a href="https://github.com/lowRISC/ibex/tree/master/dv/uvm">UVM-based
verification to the tree</a>,
and we run these tests after every change.  We run static code analysis to catch
common programming bugs. We run software on Ibex to see if it actually behaves
as we expect it to behave. For licensing reasons it hasn’t been possible to
share all of these tests - this post will
explain how we’ve been working to address that issue..</p>

<p>We want every contributor to have a similar degree of confidence that their
changes won’t break something, which is why we’ve been building out the test and
continuous integration infrastructure using open source or freely available
tooling. (I talked about the idea behind that at
<a href="https://fossi-foundation.org/wosh/">WOSH</a>, you’re invited to <a href="https://youtu.be/bYidDwYuVr0">watch the
recorded talk</a> to hear more about it!)</p>

<p>Today, we’re happy to announce a significant step in this direction: we have
enabled publicly visible continuous integration (CI) for Ibex. On every pull
request we now run three tests:</p>

<ul>
<li>We run Verilator lint on all SystemVerilog code files. Verilator lint catches
common programming errors such as undefined variables or wrong signal width
definitions.</li>
<li>We build a cycle-accurate compiled simulation of Ibex with
Verilator.</li>
<li>Finally, we run the <a href="https://github.com/riscv/riscv-compliance/">RISC-V compliance test
suite</a> with our cycle-accurate
simulation model of Ibex. This test suite executes a set of small assembly
programs and checks its output against a golden reference.</li>
</ul>

<p>All of these tests run in a couple of minutes, and all test outputs are <a href="https://dev.azure.com/lowrisc/ibex/_build">publicly
visible at Azure Pipelines</a>.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/ICwC_Azure_Pipelines_hu45f6c4d9bbd323d969e4472f476ff7f5_32506_500x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/ICwC_Azure_Pipelines_hu45f6c4d9bbd323d969e4472f476ff7f5_32506_1000x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/ICwC_Azure_Pipelines_hu45f6c4d9bbd323d969e4472f476ff7f5_32506_500x0_resize_box_2.png"alt='Azure pipeline' title='Azure pipeline' class=''
  >





<p>The last test is worth explaining in more depth. The RISC-V Compliance test
suite is a collaborative effort by the RISC-V Foundation Compliance Task Group
to test RISC-V implementations for specification compliance. Lee Moore from
Imperas has been doing a lot of <a href="https://github.com/riscv/riscv-compliance/commit/25d14e798eb4b3a54bdf22083940e78ef731b817">work to get the test suite extended to work
with
Ibex</a>,
and we have done our part by <a href="https://github.com/lowRISC/ibex/pull/209">adjusting the simulation model of
Ibex</a> to work with it. Once these
building blocks were in place it was only a matter of a <a href="https://github.com/lowRISC/ibex/blob/e97931c8c75aad34137db99121249fa675bc9aa3/azure-pipelines.yml#L102-L125">couple of lines of
configuration</a>
to enable these tests to run in CI.</p>

<p>With all this infrastructure in place, contributors can submit pull requests
with more confidence than ever: look out for the green check mark under a pull
request!</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/ICwC_checks_passed_hub7563b2a4f05d2620940ea97cf8891c6_4446_500x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/ICwC_checks_passed_hub7563b2a4f05d2620940ea97cf8891c6_4446_1000x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/08/ibex-code-with-confidence/ICwC_checks_passed_hub7563b2a4f05d2620940ea97cf8891c6_4446_500x0_resize_box_2.png"alt='Screenshot show checks passed' title='Screenshot show checks passed' class=''
  >





<p>We are delighted that Ibex can now serve as a <a href="https://github.com/google/riscv-dv#end-to-end-rtl-and-iss-co-simulation-flow">reference end-to-end RTL and ISS
co-simulation flow for
riscv-dv</a>
and for running the RISC-V compliance suite on an RTL simulation. The
DARPA-funded <a href="https://github.com/The-OpenROAD-Project/alpha-release">OpenROAD</a>
open source EDA toolchain initiative have also <a href="https://github.com/The-OpenROAD-Project/alpha-release/tree/master/flow/designs/src/ibex">included
Ibex</a>
as a standard test case.</p>

<p>For us at lowRISC, this is just the start of the automation journey. Continuous
integration in open source hardware projects is uncharted territory for many
reasons, with licensing of proprietary tools adding further complicationWe will
continue to expand the coverage of our publicly available continuous
integration, and we’ll keep you updated here!</p>
 ]]></description></item><item><title>Six more weeks of Ibex development - what&#39;s new?</title><link>https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/</link><guid>https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/</guid><pubDate>Fri, 19 Jul 2019 20:00:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>In the past months, we have invested considerable effort in improving our
RISC-V core <a href="https://github.com/lowRISC/ibex/">Ibex</a>. This 2-stage, in-order,
32-bit microcontroller-class CPU core was <a href="https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/">contributed to us</a> by ETH Zürich in
December 2018, with activity really ramping up since May. Having been taped out
multiple times (as zero-riscy) in a mix of academic and industry projects, it
came to us as a relatively mature code base. Despite this, we have continued to
invest in improving its design and maintainability.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/ibex-cleaning-up_hu65694cd5eb21359ed9b68530746cc697_213355_200x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/ibex-cleaning-up_hu65694cd5eb21359ed9b68530746cc697_213355_400x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/ibex-cleaning-up_hu65694cd5eb21359ed9b68530746cc697_213355_200x0_resize_q75_box.jpg"alt='Carl the Ibex' title='Ibex cleaning up' class='float-right m-2 '
  >





<p>Changes have included enhancements to functionality and improved compliance
with the latest RISC-V specification. More recently we’ve been looking beyond
that - the bare user-level ISA requirements are fairly minimal (e.g. there is
no requirement that exceptions are precise). We’ve worked on a series of
cleanups and improvements in order to provide an environment that is friendly
to programmers and usable outside of deeply embedded use cases. An additional
goal is to improve the code style and readability of the core. This is
important for long-term maintenance as well as to reduce the barrier for
engineers in industry, academics, students, and hobbyists to use and understand
the core.</p>

<p>We’ve performed a lot of refactoring on the RTL design of Ibex. This has
included a major cleanup and reorganization of critical Ibex components such as
the <a href="https://github.com/lowRISC/ibex/pull/132">main processor controller</a>, the
entire <a href="https://github.com/lowRISC/ibex/pull/120">instruction-decode stage</a>,
and streamlining the interaction between those blocks. As well as improving the
understandability of the core this allowed us to get rid of a painful control
loop and to correct the handling of interrupts and exceptions.</p>

<p>Here are some numbers to give you an idea on the extent of our efforts over the
past few months. Since we started to intensify our work on Ibex in early May,
we pushed 132 Git commits to the Ibex repository which modified its RTL,
inserting 3495 lines and deleting 3026 of them (not including initial mostly
cosmetic commits and coding style changes). The whole RTL consists of 7,001
lines of code. In other words, during the last 2.5 months, roughly 50 percent
of the RTL was refactored.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/2019-07-ibex-diffstat_hu250af2e03ab3c37490408386dbbab7d6_72638_500x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/2019-07-ibex-diffstat_hu250af2e03ab3c37490408386dbbab7d6_72638_1000x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/07/six-more-weeks-of-ibex-development-whats-new/2019-07-ibex-diffstat_hu250af2e03ab3c37490408386dbbab7d6_72638_500x0_resize_box_2.png"alt='Ibex diffstat' title='Ibex diffstat' class='m-2 d-block mx-auto '
  >





<p>Ultimately, having a clean codebase helps maintainability and eases a lot the
implementation of new features and bug fixes. To this end, our refactoring
efforts definitely start to pay off. Including all bug reports since May, our
average time between receiving an issue report and and merging the
corresponding bug fix into the master branch at roughly two working days.</p>

<h2 id="from-bug-report-to-fix-in-two-days-the-power-of-open-source:a2dc4fa41735a76aa44f457911fadd1d">From bug report to fix in two days: the power of open source</h2>

<p>Looking at those bug reports we note a gradual shift on where they are coming
from and how the bugs are found, with an increasing proportion of bug reports
seeming to come from industry users. We have been desligned with the feedback
we get and the interaction we are having from companies, individuals, and
researchers, in private communications and especially via the public bug
tracker on GitHub. This definitely helps us to improve Ibex, but also our
processes. And it is an enriching experience!</p>

<p>Furthermore, there is definitely a growing interest in formal verification in
industry. On our side, we have been working together with our collaborators to
include support for the <a href="https://github.com/SymbioticEDA/riscv-formal/">RISC-V Formal Interface
(RVFI)</a> and to incorporate the
<a href="https://github.com/google/riscv-dv">RISCV-DV instruction generator</a>.
Meanwhile, many bugs reported to us are found by means of formal verification,
often covering corner cases or cases where the requirements of the
specification are very minimal. The code was already mature and the design
silicon proven when we first started work, but thanks to the combination of
open source, our own engineering efforts, and the powerful community growing
around this work we can go much beyond that. At a rapid pace we’re able to make
Ibex fully compliant with the recently ratified RISC-V Specification, we’re
making it more friendly to get started with, and we’re also making it more
straightforward to hack on.</p>

<p>Do you have something you want Ibex to do? Let us know by opening an issue on
GitHub! Our next priorities support for <a href="https://github.com/lowRISC/ibex/issues/8">Physical Memory Protection
(PMPs)</a> and
<a href="https://github.com/lowRISC/ibex/issues/88">U-mode</a>, with more to follow.</p>

<p>But why stop there? You can make hacking on Ibex and other exciting projects
your day job! lowRISC is hiring, and you can find details on all of our current
roles on our <a href="https://www.lowrisc.org/jobs/">jobs page</a>.</p>

<p><em>Philipp Wagner and Pirmin Vogel</em></p>
 ]]></description></item><item><title>Large-scale RISC-V LLVM testing with Buildroot</title><link>https://www.lowrisc.org/blog/2019/07/large-scale-risc-v-llvm-testing-with-buildroot/</link><guid>https://www.lowrisc.org/blog/2019/07/large-scale-risc-v-llvm-testing-with-buildroot/</guid><pubDate>Wed, 10 Jul 2019 16:10:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>A few years ago lowRISC started developing a new LLVM backend targeting RISC-V.
Rather than copying and modifying an existing backend, in an ad hoc fashion, we
started from scratch and proceeded systematically. This approach proved
successful in producing a high-quality codebase. We <a href="https://www.lowrisc.org/blog/2019/07/risc-v-llvm-backend-in-clang-llvm-9.0/">recently announced</a> on the llvm-dev mailing
list that the backend is now reaching stability and could be promoted from its
current status of experimental to an official target. This post explains how
our testing strategy has evolved as the compiler matured.</p>

<p><strong>TL;DR</strong>: we now successfully compile more than 90% of the 2000+ Linux packages
built by the <a href="https://buildroot.org/">buildroot</a> tool. The remaining packages
mostly fail due to relying on GCC-specific C constructs and configurations,
and not due to anything fundamental related to the new backend.</p>

<p>During the initial development of the backend our testing approach consisted
mostly of unit tests. As each feature was implemented corresponding unit tests
were added. This was done both to document the expected behaviour of the
compiler and to ensure that future LLVM changes would not introduce regressions
in those areas.</p>

<p>More recently, we started compiling entire programs using Clang targeting
RISC-V, to exercise the backend using real-world code. We started with a few
small programs and have now moved towards compiling a full Linux userspace.</p>

<p>One of the programs we chose for our initial tests was BusyBox. BusyBox
replaces many standard UNIX programs with a single binary that mimics those
individual programs. With almost 400 &ldquo;applets&rdquo;, BusyBox provided a reasonable
amount of complexity to test. To compile it with LLVM we produced a
configuration file that enables all of the BusyBox features and that specifies
Clang as the compiler, with the correct flags to target RISC-V and find the
appropriate sysroot headers and libraries.</p>

<p>BusyBox compiled successfully at the first try. To be reasonably confident it
had been correctly compiled, we wrote a script to exercise all of the applets.
Our testing revealed that a significant portion of the commands would crash
upon launch. Investigating those crashes revealed that they all had a common
cause, which was that BusyBox relied on C undefined behaviour and LLVM HEAD
would optimize away code that was intended to run. So, in fact, this issue
wasn’t specific to the new RISC-V target. We <a href="http://lists.busybox.net/pipermail/busybox/2019-June/087337.html">submitted a patch upstream</a> fixing
the issue, with which BusyBox now runs without problems.</p>

<p>Our initial testing of a handful of programs and libraries used QEMU Linux user
mode emulation for a quick and convenient testing. Next, we moved to building a
complete rootfs that we could boot with qemu-system as a sanity check, before
starting to compile large amounts of packages. For that we chose the buildroot
tool.</p>

<p>Buildroot can be used either with an existing toolchain or by letting it build
its own. To facilitate the testing process, we let buildroot build its own
GCC-8 RISC-V cross-compiler, and we then patch the resulting toolchain to use
Clang / LLVM when desired, by using a wrapper script. For our sanity check we
included a handful of programs, such as some simple command line utilities and
the nginx web server. The wrapper script will redirect the compilation to
Clang, adding a few additional command line options in the process to correctly
configure the toolchain. The wrapper can also remove a few GCC-specific
compilation flags that Clang doesn’t know about, cutting down on the
compilation noise, although that isn’t strictly necessary for basic testing.
With this approach we produced a full Linux system we could boot with QEMU.
From within QEMU we saw that we could login into the system and use it
normally, including making HTTP requests served by nginx.</p>

<p>In the terminal session below you can see me booting a clang-built rootfs
(everything other than the kernel, opensbi, and glibc is built by Clang) in
qemu, and browsing the web using links:</p>

<script id="asciicast-9Cde6gZq8KljgZD50BhLFSms6" src="https://asciinema.org/a/9Cde6gZq8KljgZD50BhLFSms6.js" async></script>

<p>Once we had a bootable system we wanted to determine how many packages we could
build. We also wanted this process to be easily reproducible, to be able to
check for compiler regressions, changes in code quality and so on. This would
require making the testing tools smarter since normally any buildroot
compilation failure will halt the build process. We extended the testing tools
to produce a tree of package dependencies, to be able to build individual
packages, and to build the individual packages in the correct order to satisfy
their dependencies. The tools are also able to apply per-package workarounds,
to avoid problems caused by some packages that depend on very GCC-specific
behaviour. This includes packages that refuse to compile unless the compilation
is warning-free and are then tripped by Clang’s additional diagnostic messages.</p>

<p>Of the 2000+ packages that buildroot provides we are now able to compile more
than 90% of them. We are still triaging a few of the remaining failing packages
to see if there are any actionable compiler issues, or if those failures also
relate to trivial configuration issues.</p>

<p>As next steps, we expect to do some more in-depth testing of the compiled
packages and to start building the Linux kernel with Clang. We will also
further investigate code size and generated code performance.</p>

<p><em>Luís Marques</em></p>
 ]]></description></item><item><title>The RISC-V LLVM backend in Clang/LLVM 9.0</title><link>https://www.lowrisc.org/blog/2019/07/risc-v-llvm-backend-in-clang-llvm-9.0/</link><guid>https://www.lowrisc.org/blog/2019/07/risc-v-llvm-backend-in-clang-llvm-9.0/</guid><pubDate>Wed, 10 Jul 2019 16:00:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>On Monday I
<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-July/133724.html">proposed</a>
promoting the upstream RISC-V LLVM backend from &ldquo;experimental&rdquo; to &ldquo;official&rdquo;
for the LLVM 9.0 release. Responses so far are <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-July/133740.html">extremely
positive</a>, and
we&rsquo;re working to ensure this is a smooth process. This means that from 9.0, the
RISC-V backend will be built by default for LLVM, making it usable out of the
box for standard LLVM/Clang builds. As well as being more convenient for end
users, this also makes it significantly easier for e.g. Rust/Julia/Swift and
other languages using LLVM for code generation to do so using the
system-provided LLVM libraries. This will make life easier for those working on
RISC-V ports of Linux distros encountering issues with Rust dependencies. As
<a href="https://www.lowrisc.org/blog/2019/07/introducing-sam/">Sam mentioned yesterday</a>, we aim to work with the upstream
Rust community to help unblock this. 9.0 will branch on the 18th of July with
the release scheduled for the 28th of August.</p>

<p>The LLVM project is a popular open source suite of compiler toolchain related
tools. The core LLVM library and Clang C/C++ front-end are the most
recognisable components. See the <a href="https://llvm.org/">project home page</a> for
more background.</p>

<p>I started the upstream RISC-V LLVM effort towards the end of 2016, having
developed and maintained an out-of-tree backend for a research architecture for
a number of years. At the time, there was some downstream work heavily based on
the MIPS backend but it had a range of problems. In order to maximise the value
from upstream code reviews (and also provide a useful reference for LLVM
newcomers), great care was taken to ensure backend functionality could be built
up incrementally. I&rsquo;m delighted that this has frequently been picked out by the
LLVM community as the golden standard to follow when contributing new targets.</p>

<h2 id="status:8c1693179c5c417d4b8c4ef0915dfc6c">Status</h2>

<p>The RISC-V backend supports the 32- and 64-bit RISC-V base ISAs and all
standard extensions. i.e. RV32IMAFDC, RV64IMAFDC and the ilp32, ilp32f, ilp32d,
lp64, lp64f, lp64d ABIs (the <a href="https://reviews.llvm.org/D60456">Clang hard-float ABI
patch</a> will land imminently). Working with
other backend contributors, we have developed a comprehensive set of in-tree
unit tests. For quite some time various groups have reported success using
Clang/LLVM for their RISC-V embedded firmware builds and more recently we have
been pushing forwards on issues related to building Linux/BSD applications. The
GCC torture suite has a 100% pass rate, we&rsquo;re seeing a 98% pass rate on the
LLVM test-suite (failures are almost all related to C++ exception handling,
which we hope to resolve soon), and we&rsquo;ve been able to get over 90% of
buildroot&rsquo;s over 2000 packages to build for RISC-V using clang (most failures
are due to build system issues or GCCisms). We can compile and run meaningful
programs e.g.  build a rootfs with nginx, serve HTTP requests). See the <a href="https://www.lowrisc.org/blog/2019/07/large-scale-risc-v-llvm-testing-with-buildroot/">blog
post from Luis</a> for many more
details on this testing.</p>

<p>LLD support is now roughly feature-complete with the exception of support for
linker relaxation. Fangrui Song has been most active on RISC-V LLD recently,
and prior to that Andes Tech contributed the majority of this code. In terms of
other language support, there is initial Rust support for bare metal RV32 and
RV64 with support for hard float Linux targets due to start soon.</p>

<p>Support for RISC-V in LLVM is important for the wider RISC-V ecosystem and at
lowRISC, we&rsquo;re proud of the role we&rsquo;ve played in initiating its development,
driving it forwards, and building a community around it. As an independent
non-profit engineering organisation, we&rsquo;re uniquely positioned to perform this
kind of work - <a href="https://www.lowrisc.org/our-work/">it&rsquo;s what we do</a>. Our toolchain team has
grown to include Luís Marques and Sam Elliott as well as myself and we are
always interested in hearing from skilled engineers who’d like to <a href="https://www.lowrisc.org/jobs/">join our
team</a>. If you&rsquo;re interested in further supporting this work
or in applying a similar approach to other open source hardware/software
projects then get in touch at info@lowrisc.org.</p>

<h2 id="thanks:8c1693179c5c417d4b8c4ef0915dfc6c">Thanks</h2>

<p>As well as the lowRISC toolchain team I would like to thank everyone who gave
encouragement, helped with funding in order to support this work, or submitted
reviews or patches. We&rsquo;re delighted at the growing community of contributors
around this backend and feel it&rsquo;s a real success story for collaboration within
the RISC-V ecosystem. There are far too many names to mention everyone, but
engineers from organisations such as (alphabetically) AndesTech, Embecosm,
Google, Qualcomm, and the University of Cambridge have all made notable
contributions.</p>

<h2 id="next-steps:8c1693179c5c417d4b8c4ef0915dfc6c">Next steps</h2>

<p>Becoming an &ldquo;official&rdquo; backend is a huge milestone, but of course that doesn&rsquo;t
mean we&rsquo;re done. As well as ongoing maintenance and support, we&rsquo;ll be
continuing to work on: code size, generated code performance improvements,
better testing, collaborating with language communities such as
Rust/Swift/Julia, adding support for additional LLVM features or RISC-V
instruction set extensions, and more.</p>

<p><em>Alex Bradbury, CTO and Co-Founder</em></p>
 ]]></description></item><item><title>Introducing Sam</title><link>https://www.lowrisc.org/blog/2019/07/introducing-sam/</link><guid>https://www.lowrisc.org/blog/2019/07/introducing-sam/</guid><pubDate>Mon, 08 Jul 2019 10:00:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>On June 1st, Sam Elliott followed <a href="/blog/2019/06/introducing-pirmin-laura/">Laura and
Pirmin</a> in becoming lowRISC’s newest
employee. A few weeks into his new role, he shares why he joined lowRISC and
what he&rsquo;s been doing since he started.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/07/introducing-sam/sam_elliott_hu91ba7eb7dc6f13af8e8f1b3ab202b74f_102174_300x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/07/introducing-sam/sam_elliott_hu91ba7eb7dc6f13af8e8f1b3ab202b74f_102174_600x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/07/introducing-sam/sam_elliott_hu91ba7eb7dc6f13af8e8f1b3ab202b74f_102174_300x0_resize_q75_box.jpg"alt='Sam Elliot' title='Sam Elliot' class='float-right m-2 '
  >





<p>&ldquo;I joined lowRISC CIC as a Compiler Developer, working on the RISC-V LLVM
backend, and so far I’m enjoying working on the team! Prior to lowRISC, I worked
as a compilers and programming languages researcher at the University of
Washington, where I completed my Masters degree.</p>

<p>&ldquo;I worked for about four years on the academic side of compiler research, trying
out new ideas with new technologies. As well as working with academics, during
that time I worked at Microsoft Research, on <a href="https://www.microsoft.com/en-us/research/project/checked-c/">Checked
C</a>, and at NVIDIA
on an experimental compiler team. This was both challenging and fun, but I found
that I was more satisfied with the work when it was closer to problems that
normal software developers face. I’m really happy to have moved over to a more
focused compiler development role on the team here at lowRISC, where I get to
improve LLVM and participate in the wider open source community.</p>

<p>&ldquo;My first month at lowRISC has been lots of fun. Alex and Luís have been great
mentors to get me up to speed with the project. As we’re hoping to stabilise the
RISC-V backend soon, some of my time has been spent ensuring we can build and
run the LLVM <a href="https://llvm.org/docs/TestingGuide.html#test-suite">test suite</a> on
RISC-V. Gratifyingly, it seems 98% of the tests are passing – with some pending
patches – and the rest are not far from also doing so. A few of the other
patches I have committed this month have related to tuning the optimiser and
instruction selector to make better decisions for RISC-V. Of course, we’ll never
truly finish tuning the optimiser, especially as more and more instruction set
extensions and open cores are implemented and released.</p>

<p>&ldquo;On top of all of this, it was good to get out of the office and meet other
RISC-V and open-source hardware supporters at the RISC-V Workshop and WOSH in
Zurich. It was an almost overwhelming amount of information for someone so new
to the ecosystem, but the community has been very friendly and welcoming.</p>

<p>&ldquo;I’m not just interested in how programs can be compiled to be as efficient as
possible; I’m also interested in how the design of programming languages allow
developers to write programs that contain fewer errors. This is why I joined the
Checked C project, and am interested in Rust. Along these lines I am beginning
to look at improving the support for compiling Rust programs to RISC-V. Rust
uses LLVM as a backend, so a lot of the work is already done, but we want to
make sure the experience of using Rust on RISC-V is as good as it is for any
other platform. Rust support is a key requirement for the RISC-V ports of
distros such as Debian and Fedora, and I look forward to helping stabilise
further support for the platform in these distributions.</p>

<p>&ldquo;Having stable RISC-V support in both the Clang and Rust compilers, in addition
to the existing support in GCC, should allow more people and projects to adopt
RISC-V and quickly get started on the platform.&rdquo;</p>

<hr />

<p>We&rsquo;re excited to have Sam join our team and help further accelerate our
toolchain and LLVM-related efforts. If you&rsquo;re interested in joining us on our
mission, check out our <a href="https://www.lowrisc.org/jobs/">jobs page</a> for details on
positions we are looking to fill.</p>

<p><em>Alex Bradbury, CTO and Co-Founder</em></p>
 ]]></description></item><item><title>lowRISC at Week of Open Source Hardware</title><link>https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/</link><guid>https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/</guid><pubDate>Tue, 11 Jun 2019 16:00:00 +0100</pubDate><author>info@lowrisc.org (Andrew Back)</author><description><![CDATA[ 









  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/WOSH_logo_640w_hu1b3ad08286e7307a189c04a1da303d38_52934_200x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/WOSH_logo_640w_hu1b3ad08286e7307a189c04a1da303d38_52934_400x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/WOSH_logo_640w_hu1b3ad08286e7307a189c04a1da303d38_52934_200x0_resize_box_2.png"alt='WOSH logo' title='WOSH logo' class='float-right m-2 '
  >





<p>Pretty much the whole team is in Zurich this week for the RISC-V Workshop and
inaugural Week of Open Source Hardware, with a <a href="https://fossi-foundation.org/wosh/">packed
programme</a> that got off to a start today and
which runs all the way through to Friday afternoon.</p>

<p>This morning lowRISC board member, Professor Luca Benini, gave a RISC-V Workshop
keynote entitled, <a href="https://tmt.knect365.com/risc-v-workshop-zurich/agenda/1#keynotes_energy-efficient-computing-from-exascale-to-microwatts-the-risc-v-playground">Energy efficient computing from Exascale to MicroWatts: The
RISC-V
playground</a>.
Our friends and close collaborators at <a href="https://pulp-platform.org/">PULP
Platform</a> are giving a number of talks this week
and, we’re pleased to say, so are members of the lowRISC team!</p>

<p>On Thursday 13th there will be a morning session dedicated to <a href="https://fossi-foundation.org/wosh/#licensing">Open Source
Licensing</a> and at 10:50 Alex
Bradbury will be presenting <a href="https://fossi-foundation.org/wosh/#event-abstract-5">a lowRISC experience
report</a>, immediately
following which he’ll then be participating in a panel discussion moderated by
the <a href="https://fossi-foundation.org/">FOSSi Foundation</a>’s Stefan Wallentowitz.
Later the same day at 16:10, Google engineer and lowRISC board member, Dom
Rizzo, will be speaking about <a href="https://fossi-foundation.org/wosh/#event-abstract-7">Google and the Free and Open Source Hardware
Community</a>.</p>

<p>The following day on Friday 14th at 09:20, Philipp Wagner will be giving a talk
entitled, <a href="https://fossi-foundation.org/wosh/#event-abstract-2">Ibex and The Mountain of Open Participation: How lowRISC develops its
Ibex CPU core and lets everyone
participate</a>. Then Philipp
will be taking to the stage for a second time at 14:40 to give another talk on
<a href="https://fossi-foundation.org/wosh/#event-abstract-4">Python-powered hardware verification with
Cocotb</a>.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/lowRISC_enamel_badge_640w_hu45977cb0bfc770fd7ffa0509577547f2_53634_640x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/lowRISC_enamel_badge_640w_hu45977cb0bfc770fd7ffa0509577547f2_53634_1280x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/06/lowrisc-at-week-of-open-source-hardware/lowRISC_enamel_badge_640w_hu45977cb0bfc770fd7ffa0509577547f2_53634_640x0_resize_q75_box.jpg"alt='lowRISC enamel badge' title='lowRISC enamel badge' class='m-2 d-block mx-auto '
  >





<p>If you’re in Zurich this week please do say hello and if you can’t spot us from
the team photo <a href="https://www.lowrisc.org/about/">on the website</a> — it already
needs updating! — be sure to follow the <a href="https://twitter.com/lowrisc">Twitter
feed</a> for team updates and also be on the lookout
for people wearing a lowRISC pin.</p>
 ]]></description></item><item><title>An update on Ibex, our microcontroller-class CPU core</title><link>https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/</link><guid>https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/</guid><pubDate>Mon, 10 Jun 2019 15:00:00 +0100</pubDate><author>info@lowrisc.org (Philipp Wagner)</author><description><![CDATA[ <p>At the beginning of many chips projects, there’s a dream. Could we create a more
future-proof chip by embedding an FPGA fabric into it? Could we measure glucose
levels more accurately by integrating a small bio lab onto a chip? Could we more
reliably recognize kittens in a set of pictures by implementing neural network
inference in hardware?</p>

<p>In implementation, this dream becomes a piece of hardware, with digital or
analog logic, sensors, actuators, and much more. Let’s get it produced and try
out the real thing! But wait. How do you control the hardware block? How do you
feed data to it? How do you make sure the startup sequence is done exactly in
the right way? The answer often is: add an embedded micro-controller core to
handle the control logic. A small, efficient, and rock-solid core. Where could
you get such a core?</p>

<p>Say hello to Ibex: a small, 32-bit microcontroller-class RISC-V CPU core written
in SystemVerilog. Reliable, unpretentious, getting the job done.</p>

<ul>
<li>Ibex supports the standard RV32I/EMC instruction set, allowing you to tap into
a large ecosystem of compilers and software libraries.</li>
<li>Its two stage pipeline design balances a small area overhead with good
performance. It gives you an IPC of 0.67 in CoreMark (2.44 CoreMarks/MHz) with
an area of just 18.9 kGE. That’s 0.027 mm² in a 65 nm technology!
(<a href="https://doi.org/10.1109/PATMOS.2017.8106976">Reference</a>) But Ibex works
equally well on FPGAs. The same configuration utilizes 2.5 k 6-input Slice LUTs
and 1 DSP slice on low-end Xilinx 7-series FPGAs when targeting a clock
frequency of 50 MHz.</li>
<li>And best of all: there are no usage restrictions. Ibex is open source under
the Apache 2.0 License, <a href="https://github.com/lowRISC/ibex/">download it today</a>
and get started!</li>
</ul>

<p>So if you need a microcontroller-class CPU core, look no further and give Ibex a
try! Our friendly community awaits you <a href="https://github.com/lowRISC/ibex/">over at
GitHub</a> to discuss enhancements, issues or
help you get your favorite feature added to Ibex!</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/Ibex_block_diagram-100619_hu64d0b4d86cd0ba0563db9df884419228_38933_400x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/Ibex_block_diagram-100619_hu64d0b4d86cd0ba0563db9df884419228_38933_800x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/Ibex_block_diagram-100619_hu64d0b4d86cd0ba0563db9df884419228_38933_400x0_resize_box_2.png"alt='Ibex block diagram' title='Ibex block diagram' class='d-block mx-auto rounded m-2 '
  >





<p>If you&rsquo;re interested in using Ibex in your design, you&rsquo;d be in good company.
Researchers at the University of Manchester (with support from Andrew Attwood
from the STFC Hartree Centre) are already working on taping out a design including
the Ibex core, with reconfigurable FPGA instruction set
extensions. Do get in touch at <a href="mailto:info@lowrisc.org">info@lowrisc.org</a> if
you’re looking to integrate Ibex into one of your designs…</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/forte_placement_hue940785ad6e6ed3174e2001f0623cf05_325721_400x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/forte_placement_hue940785ad6e6ed3174e2001f0623cf05_325721_800x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2019/06/an-update-on-ibex-our-microcontroller-class-cpu-core/forte_placement_hue940785ad6e6ed3174e2001f0623cf05_325721_400x0_resize_box_2.png"alt='University of Manchester design with Ibex core' title='University of Manchester design with Ibex core' class='d-block mx-auto m-2 '
  >





<p>Ibex stands on an impressive mountain of engineering, erected by many great
people mostly at ETH Zürich and the University of Bologna. Before <a href="/blog/2019/05/lowrisc-expands-press-release/">it was
contributed to
lowRISC</a> in
December 2018, Ibex was called Zero-riscy. The history of the core can be traced
back to a CPU core called “OR10N”, which was first taped out in 2013. Since that
time, many, many hours of engineering, testing,
and benchmarking went into what is now Ibex. That’s why it is such a solid
design, and that’s the legacy lowRISC is proud to build upon.</p>

<p>lowRISC started working on Ibex around the time I joined the engineering team,
since then we’ve been able to make a range of improvements in collaboration with
our partners at Google and ETH Zürich, with <a href="/blog/2019/06/introducing-pirmin-laura/">Pirmin also
joining</a> the
effort recently.</p>

<p>One of the first things we did with Ibex was the replacement of the debug system
with one that is compliant to the RISC-V Debug Specification. (Thanks to Robert
Balas and Davide Schiavone who started this work on a similar CPU core!) We also
cleaned up the code in many places to make it easier to read and extend. And
just recently Tao Liu from Google added a UVM testbench to make it easier to
verify that the core works as expected.</p>

<p>Importantly, this is an active and ongoing effort. With the engineering and
project maintenance resources lowRISC and our partners are putting into Ibex and
related IP blocks, we aim to make it the make Ibex <em>the</em> go-to
microcontroller-class CPU core. Our <a href="https://github.com/lowRISC/ibex/issues">issue tracker on
GitHub</a> should give you a rough idea of
what’s coming.</p>

<p>Do you want to join us making Ibex even better? For example, do you want to set
up world-class continuous integration for this core? lowRISC is hiring, and
we’re looking for a broad range of engineers: hardware, software and tooling.
<a href="/jobs/">Join us!</a></p>

<p>You want to know more about Ibex and how lowRISC develops it to be a piece of
high-quality free and open source IP? <a href="https://fossi-foundation.org/wosh/">Join Philipp for a talk at the Week of
Open Source Hardware (WOSH) in Zürich, Switzerland on Friday, June
14.</a></p>
 ]]></description></item><item><title>Introducing Pirmin &amp; Laura</title><link>https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/</link><guid>https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/</guid><pubDate>Mon, 03 Jun 2019 10:00:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>Pirmin Vogel and Laura James both joined lowRISC on May 1st this year. A few
weeks in to their new roles, they each share thoughts on what attracted them to
work at lowRISC.</p>

<p><strong>Pirmin:</strong></p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/pirmin_vogel_hu6f1273808d0ebccd5191e8dc5d8bbc37_50344_300x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/pirmin_vogel_hu6f1273808d0ebccd5191e8dc5d8bbc37_50344_600x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/pirmin_vogel_hu6f1273808d0ebccd5191e8dc5d8bbc37_50344_300x0_resize_q75_box.jpg"alt='Pirmin Vogel' title='Pirmin Vogel' class='float-right m-2 '
  >





<p>&ldquo;After having traveled around the world for 6 months, I finally started my new
position as hardware/software engineer at lowRISC C.I.C. in Cambridge at the
beginning of May. At lowRISC, we are working on open-source hardware/software
ecosystems with a fully open-sourced, Linux-capable, RISC-V-based SoC being the
ultimate goal.</p>

<p>&ldquo;Having done my PhD in the Digital Circuits and Systems group of ETH Zurich,
i.e., a research group that very early started to promote and push for
open-source hardware, it was important for me to continue along the open-source
path. Open-source hardware and software are powerful catalysts for education,
research and industry. Studying the sources of the Linux kernel and its modules
was absolutely key to get to understand the kernel’s memory management system
and to get started with the design of kernel drivers required for my research.
Moreover, building on top of the open-source Parallel Ultra Low Power (PULP)
Platform allowed me to carry out my research in the first place. Not only could
I rely on a large pool of silicon-proven hardware designs and software tools
such as libraries, runtimes and compilers, but I was also able to freely modify,
tailor and extend them to fit my needs, and ultimately to release my own
research open-source as part of the <a href="https://www.pulp-platform.org/hero">Open Heterogeneous Research Platform</a> (HERO), thereby letting my research being more
useful to more people. As for the industry, it seems that the open-source PULP
ecosystem has gained quite some traction since its start in 2013 serving both as
a starting point for custom designs and also creating <a href="https://www.pulp-platform.org/pulp_users.html">new business opportunities</a>.</p>

<p>&ldquo;At lowRISC, I am currently working on our RISC-V processor core <a href="https://github.com/lowRISC/ibex">Ibex</a>. This core has its origins in academia – it
has been designed by my former colleagues of the PULP team under the name
Zero-riscy – and leveraging its design in a professional context offers
challenges but also new opportunities. For example, it allows and requires to
put a stronger focus on design verification but ultimately, it can prove also to
the tough critics that open-source hardware is no longer just a toy but a
serious alternative.&rdquo;</p>

<p><strong>Laura:</strong></p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/laura_james_huc53354b671e9769f849faa1d4a5d9683_101541_300x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/laura_james_huc53354b671e9769f849faa1d4a5d9683_101541_600x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/06/introducing-pirmin-laura/laura_james_huc53354b671e9769f849faa1d4a5d9683_101541_300x0_resize_q75_box.jpg"alt='Laura James' title='Laura James' class='float-right m-2 '
  >





<p>&ldquo;I’m delighted to be joining lowRISC. This is a really exciting
opportunity for me on many levels - a chance to be part of a new wave of
fundamental computing innovation enabling specialised silicon chips, to learn
about the practicalities of shared engineering resource and IP at the hardware
layer, and to actually ship some useful products (hopefully at reasonable
scale). It builds on my varied career to date working to make emerging
technologies a reality in real products and services, and in growing innovative
organisations.</p>

<p>&ldquo;lowRISC works on open source hardware at the silicon layer (and related open
source software tools), and so builds on my longstanding interest in open stuff,
and particularly the challenges of bringing open to new areas. Open source
silicon isn&rsquo;t a totally new idea, but producing products at scale with it is
rare. Nonetheless, it&rsquo;s important: openness means greater scope for audit and
security; for efficiency (code and hardware designs can be reused, rather than
reinventing the wheel), and for flexibility. With <a href="https://semiengineering.com/the-impact-of-moores-law-ending/">Moore&rsquo;s law
slowing down</a>, new
processors will be more specialised, rather than just smaller and faster.
Instead, we&rsquo;ll be designing silicon for more specific applications, and ensuring
the designs are efficient and verifiable. Open source hardware makes this much
easier - you can get more people working on a design to check it, and you can
bolt together open modules for different bits of functionality knowing you
understand what is in them (which you can&rsquo;t do with a proprietary processor core
which you&rsquo;ve licensed - it&rsquo;s just a black box). So open hardware at the silicon
level is going to be important for the future of computing.</p>

<p>&ldquo;lowRISC itself is still quite small (but growing), but the team size doesn&rsquo;t
reflect the range of people I’m working with day to day, because there&rsquo;s lots of
collaboration going on. Open source ecosystems have different kinds of
organisation and activity in them; lowRISC is focussing on providing quality
engineering resource and being a hub for collaborative engineering across other
partners. (A bit like <a href="https://www.linaro.org/">Linaro</a> does for open source for
Arm, whose work I’ve always been fascinated by.)  It&rsquo;s a community interest
company, meaning a nonprofit dedicated to serving a broader mission not just
itself. I&rsquo;m looking forward to being part of changing how hardware is developed,
making it fundamentally more collaborative and factoring in testing and
maintenance sensibly.</p>

<p>&ldquo;There are some really interesting challenges. For instance, you can&rsquo;t be 100%
open right now in silicon, because in an actual manufactured chip there&rsquo;s a lot
of analogue components as well as the open source digital bits, and those
analogue bits are generally closely linked to the big foundries which
manufacture silicon and are secret sauce today.  Collaborative engineering
should be cost effective and useful to companies, as a way of working on
non-differentiating technology components, but it&rsquo;s not always an easy sell or
easy to make happen in practice. The same goes for opening up hardware IP - not
always a straightforward case to make. How should the governance for this sort
of work operate, and how do you make it work in practice? And of course we have
the usual startup challenge, that we need to make reliable, high quality
products, in a reasonable time, which people actually want and are willing to
pay for.</p>

<p>&ldquo;I’m really looking forward to seeing what we can accomplish, and being part of
the move towards open source silicon.</p>

<p>&rdquo;(If you’d like to learn more about how I ended up here, I wrote on <a href="https://lbj20.blogspot.com/2019/04/new-challenges-ahead.html">my personal
blog</a> about this
role and how it fits with things I’ve been working on.)&rdquo;</p>

<hr />

<p>We&rsquo;re thrilled to have Pirmin and Laura join the lowRISC team and if you&rsquo;d like
to be part of the open source silicon revolution, we presently have a number
of openings and I&rsquo;d encourage you to take a look at the <a href="https://www.lowrisc.org/jobs/">jobs page</a>.</p>

<p><em>Alex Bradbury, CTO and Co-Founder</em></p>
 ]]></description></item><item><title>Onwards and upwards at lowRISC</title><link>https://www.lowrisc.org/blog/2019/05/onwards-and-upwards-at-lowrisc/</link><guid>https://www.lowrisc.org/blog/2019/05/onwards-and-upwards-at-lowrisc/</guid><pubDate>Thu, 16 May 2019 18:40:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>If you haven&rsquo;t checked it out yet, be sure to take a look at our <a href="https://www.lowrisc.org/blog/2019/05/lowrisc-expands-press-release/">press
release</a> and the
<a href="https://opensource.googleblog.com/2019/05/google-fosters-open-source-hardware.html">corresponding Google blog
post</a>.
This industry support and growth of our board is a huge step forwards for
lowRISC. As Royal Hansen, vice president of Security, Google, said:</p>

<blockquote>
"Google believes that open source is good for everyone. To further our
commitment, we are investing both capital and engineering resources to create
a sustainable open source hardware ecosystem. In addition to engineering
resources, lowRISC provides the community stewardship that is vital to this
vision”.
</blockquote>

<p>We believe high quality engineering, extensive documentation, and
verification are essential to drive the adoption of open source silicon
designs. The donation of the <a href="https://github.com/lowrisc/ibex">Ibex</a> core
(previously zero-riscy, developed through the PULP project) and its collaborative development under lowRISC is a
great step forwards on the open source hardware roadmap we&rsquo;re working on with
Google and other industry partners. Plus of course we’re continuing to lead the upstream RISC-V LLVM effort and further develop our 64-bit SoC platform. If you&rsquo;re interested in collaboration, get in touch via info@lowrisc.org.</p>

<p>Over the last 6 months we&rsquo;ve really entered a new phase of the lowRISC mission.
We&rsquo;ve grown from a single full-time engineer to five, with more on their way
(check out our <a href="https://www.lowrisc.org/jobs/">active job adverts</a> - we&rsquo;d love to hear
from you!). We&rsquo;ve not been able to put out anywhere near as many updates as
we&rsquo;d like. The work we&rsquo;ve been doing to grow the organisation and forge new
collaborations is hugely time consuming, and of course embargos etc. come in to
play. But you can expect to hear much more from us going forwards.</p>

<p>On a final note, I&rsquo;d like to shine the spotlight on the <a href="https://www.lowrisc.org/about/">whole lowRISC
family</a>, especially those who have helped us get this far. In
particular I’d like to thank our board of directors, our growing team of full
time staff, our technical advisory board, and of course the wider community
who have given us so much support, suggestions, and encouragement. Pirmin and
Laura will soon be posting more about their experiences joining lowRISC, and
you&rsquo;ll be seeing a number of other new faces on our
<a href="https://github.com/lowRISC">GitHub</a>, <a href="https://twitter.com/lowrisc">Twitter</a>,
and shiny new <a href="https://lowrisc.zulipchat.com/register/">Zulip group chat</a> - do
join and say hi.</p>

<p><em>Alex Bradbury, CTO and Co-Founder</em></p>
 ]]></description></item><item><title>lowRISC Expands and Appoints New Members to the Board of Directors from Google and ETH Zurich</title><link>https://www.lowrisc.org/blog/2019/05/lowrisc-expands-press-release/</link><guid>https://www.lowrisc.org/blog/2019/05/lowrisc-expands-press-release/</guid><pubDate>Thu, 16 May 2019 17:50:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p><em>London, England - lowRISC C.I.C., the open source system on a chip (SoC)
organisation, today announced that Prof. Luca Benini (ETH Zurich), Dominic
Rizzo (Google) and Ron Minnich (Google) have joined its board of directors.
The announcement coincides with a new phase of hiring by lowRISC with the goal
of significantly increasing the size of its Cambridge-based engineering team
during 2019.</em></p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/05/lowrisc-expands-press-release/board1_hu50526d94ea1a2936dbbad1660b780a0d_114705_500x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/05/lowrisc-expands-press-release/board1_hu50526d94ea1a2936dbbad1660b780a0d_114705_1000x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/05/lowrisc-expands-press-release/board1_hu50526d94ea1a2936dbbad1660b780a0d_114705_500x0_resize_q75_box.jpg"alt='lowRISC board' title='lowRISC board' class=''
  >





<p>lowRISC is a not-for-profit, community-driven organisation working to provide
a high quality, security-enabling, open SoC base for derivative designs. The
organisation is lowering the barrier to producing custom silicon, enabling
research and FPGA experimentation, and establishing a vibrant ecosystem around
open silicon designs. lowRISC supports a core engineering team who collaborate
with industry partners, academic groups, and the wider community to drive the
open source silicon ecosystem.</p>

<p>&ldquo;We are very pleased to welcome new board members from Google and ETH Zurich
who share our excitement about the future of open-source hardware. Their
commitment will accelerate our roadmap for delivering high-quality open-source
system-on-chip designs,” said Alex Bradbury, CTO and co-founder of lowRISC
CIC.</p>

<p>lowRISC also revealed that Google are providing support and funding to further
their mission and that Prof. Benini&rsquo;s group at ETH Zürich are contributing
their Zero-riscy processor core. lowRISC, in collaboration with Prof. Benini’s
PULP team and Google, will continue development of the core as
“<a href="https://github.com/lowRISC/ibex/">Ibex</a>”.</p>

<p>“I’m delighted to join the lowRISC board. lowRISC plays a key role in the
open-source hardware ecosystem, providing engineering resources while
maintaining a clear community-focused vision and not-for-profit status. We are
excited that they will be able to contribute to the continued development of
Zero-riscy and also provide the necessary ongoing support,” said Prof. Benini.</p>

<p>Google engineers Ron Minnich and Dominic Rizzo are long term supporters of
open-source. Ron is a well known figure in the High Performance Computing
field and inventor of LinuxBIOS, now known as coreboot, the firmware used in
all Chromebooks. Dominic leads efforts in open source silicon and security
fobs at Google.</p>

<p>&ldquo;Google believes that open source is good for everyone. To further our
commitment, we are investing both capital and engineering resources to create
a sustainable open source hardware ecosystem. In addition to engineering
resources, lowRISC provides the community stewardship that is vital to this
vision,” said Royal Hansen, vice president of Security, Google.</p>

<p>Please visit our <a href="https://www.lowrisc.org/jobs/">jobs</a> page for more
information on how lowRISC is expanding our engineering organization.</p>

<h2 id="about-lowrisc:3ae8a44f05106f2746ef878301015e47">About lowRISC</h2>

<p>lowRISC C.I.C. is a not-for-profit company that aims to demonstrate, promote
and support the use of open-source hardware - bringing the benefits of
open-source to the hardware world. We are producing high-quality,
security-focused, open, and flexible IP. Our expertise includes the LLVM
Compiler, novel hardware security extensions and RISC-V tools, hardware and
processor design.</p>

<p>For more information, please contact:</p>

<p>Media Contact:
Andrew Back
lowRISC
press@lowrisc.org</p>
 ]]></description></item><item><title>lowRISC at the SiFive Symposium in Cambridge</title><link>https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/</link><guid>https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/</guid><pubDate>Tue, 14 May 2019 17:58:00 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>Several lowRISC team members attended the <a href="https://sifivetechsymposium.com/agenda-cambridge/">SiFive
Symposium</a> in our home town
of Cambridge on May 13th 2019, a lovely sunny day.</p>

<p>Imagination Technologies were co-hosting with SiFive, and we heard from both
companies. Krste Asanovic, chairman of the board at the RISC-V Foundation,
gave a great introduction to RISC-V and progress so far. Naveed Sherwani, CEO
of SiFive, talked us through their silicon design platform and future
services. We also heard from SecureRF and IAR Systems.</p>

<p>Alex gave a short talk about bringing the benefits of open source to the
hardware world. (We hope to be able to share the video soon!)</p>

<p>









  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/sifive_symposium_alex1_hu61a3328a95a421a58ba08cb79b3ac197_63641_500x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/sifive_symposium_alex1_hu61a3328a95a421a58ba08cb79b3ac197_63641_1000x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/sifive_symposium_alex1_hu61a3328a95a421a58ba08cb79b3ac197_63641_500x0_resize_q75_box.jpg"alt='Alex speaking' title='Alex speaking' class='m-2 d-block mx-auto '
  >














  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/sifive_symposium_alex2_hu1398eb9b75797e637e710eb4e6174922_76782_500x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/sifive_symposium_alex2_hu1398eb9b75797e637e710eb4e6174922_76782_1000x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2019/05/lowrisc-at-sifive-symposium-in-cambridge/sifive_symposium_alex2_hu1398eb9b75797e637e710eb4e6174922_76782_500x0_resize_q75_box.jpg"alt='Open source hardware in industry' title='Open source hardware in industry' class='m-2 d-block mx-auto '
  >



</p>

<p>It was great to hear the latest news from SiFive and other RISC-V
organisations, both from Cambridge and further afield. We also got to meet
community members and to catch up with friends from Embecosm, the RISC-V
Foundation, the Computer Lab and more.</p>
 ]]></description></item><item><title>lowRISC 0-6 milestone release</title><link>https://www.lowrisc.org/blog/2018/11/lowrisc-0-6-milestone-release/</link><guid>https://www.lowrisc.org/blog/2018/11/lowrisc-0-6-milestone-release/</guid><pubDate>Mon, 12 Nov 2018 09:50:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>The <a href="https://www.lowrisc.org/docs/refresh-v0.6/">lowRISC 0.6 milestone release</a>
is now available. This release includes an updated version of the Rocket
RISC-V core, a higher core clock frequency, JTAG debugging support, Ethernet
improvements, and more. See the <a href="https://www.lowrisc.org/docs/refresh-v0.6/">release notes</a>, for full details. We&rsquo;ve also taken the
opportunity to re-organise our <a href="https://www.lowrisc.org/docs/">documentation</a>,
adding an easy to follow quick-start guide.</p>

<p>Our next development focus is to add support for dropping in the <a href="https://github.com/pulp-platform/ariane">Ariane
RISC-V design</a> (from ETH Zurich) as
an alternative to Rocket.</p>

<p>Please report any issues <a href="https://github.com/lowRISC/lowrisc-chip">on our GitHub
repository</a>, or discuss on our
<a href="http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org">mailing
list</a>.
As always, thank you to everyone who has contributed in any way - whether it&rsquo;s
advice and feedback, bug reports, code, or ideas. With special thanks to Jonathan
Kimmitt who has been the driving force behind this release.</p>
 ]]></description></item><item><title>Barcelona RISC-V Workshop: Day Two</title><link>https://www.lowrisc.org/blog/2018/05/barcelona-risc-v-workshop-day-two/</link><guid>https://www.lowrisc.org/blog/2018/05/barcelona-risc-v-workshop-day-two/</guid><pubDate>Wed, 09 May 2018 07:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2018/04/risc-v-workshop-in-barcelona-agenda/">eighth RISC-V
workshop</a> is
continuing
today in Barcleona. As usual, I&rsquo;ll be keeping a semi-live blog of talks and
announcements throughout the day.</p>

<p>Look back <a href="https://www.lowrisc.org/blog/2018/05/barcelona-risc-v-workshop-day-one/">here</a> for
the day one live blog.</p>

<p>Note that slides from most presentations are now <a href="https://riscv.org/2018/05/risc-v-workshop-in-barcelona-proceedings/">available at
riscv.org</a>.</p>

<h2 id="fast-interrupts-for-risc-v-krste-asanovic:d2f16b96a9dcad25ca9611e08b0e618f">Fast interrupts for RISC-V: Krste Asanovic</h2>

<ul>
<li>Embedded is a major use for RISC-V. There is a desire for faster interrupt
handling with support for nested preempted interrupts.</li>
<li>Summary of current RISC-V interrupts

<ul>
<li>Local interrupts are directly connected to one hart. There&rsquo;s no
arbitration between harts to service. Determine cause through xcause CSR.
Only two standard local interrupts (software, timer).</li>
<li>Global (external) interrupts are routed via the platform-level interrupt
controller (PLIC) which arbitrates between multiple harts claiming an
interrupt.</li>
</ul></li>
<li>The machine interrupt pending (mip) CSR contains bits for local software,
local timer, and external interrupts (from the PLIC). It tells you which
interrupts are present.</li>
<li>mie mirrors the layout of mip, and allows you to enable/disable interrupts.</li>
<li>mstatus keeps track of interrupt status, containing a small interrupt stack.</li>
<li>The interrupt is reported in the mcause CSR. The exception code indicates
which interrupt was responsible - you might have to then interrogate the PLIC
if it was an external interrupt.</li>
<li>mtvec (machine trap vector base) contains the address of the trap vector
(&lsquo;base&rsquo;). It also contains bits which control whether interrupts are direct
(all exceptions and interrupts jump to base) or vectored (exceptions go to
base, interrupts are vectored).</li>
<li>There&rsquo;s two parts of an interrupt: what you were doing when it happened
(state context), and what you&rsquo;re going to do. mepc and mstatus allow the
contact to be saved and restored.</li>
<li>Problems with current interrupts:

<ul>
<li>Hardware preemption is only possible by switching privileged modes</li>
<li>Fixed priority for local interrupts</li>
<li>The vector table holds jumps instructions, which can only jump +/- 1MiB. A
free register would be required to jump further, resulting in even more
instructions.</li>
<li>PLIC has variable priority, but the vectoring must be done in software.</li>
<li>The PLIC needs two memory accesses: one to claim it, one to indicate
completion.</li>
<li>The Unix ABI (which is the only one that has been standardised) requires
many registers to be saved/restored.</li>
</ul></li>
<li>Have had input via multiple proposals: Andes, Syntacore, Seagate, Liviu
Ionescu, SiFive</li>
<li>There have been discussions on the list about the interrupt handler
interface for software. It comes down to a choice between having the interrupt
handler as a regular C function (requiring save/restore of all caller-save
registers in hardware or software) or an inline handler which uses a gcc
interrupt attribute to convert the function to always callee-save every
register. Krste suggests both approaches are needed.</li>
<li>Krste explains how an &ldquo;interrupt&rdquo; attribute on a C function might work. In
this example, every register is callee-saved, so registers are saved as you
need to use them.</li>
<li>If you then went to call a function using the C ABI you need to save/restore
8 arguments, 7 temporaries, and 1 return address. Even more if you have to
save the floating point context. Krste argues that moving this to hardware
isn&rsquo;t enough, you need a new ABI to reduce the amount of state.</li>
<li>A number of options have been proposed for vectoring.

<ul>
<li>Having function pointers in a table. Downside is this is new functionality
you&rsquo;d have to add to a pipeline.</li>
<li>The SiFive proposal is to add a new +/-2GiB offset instruction which is
only visible in a new interrupt ISA mode. The advantage is the pipeline can
treat this as a regular instruction fetch, albeit with a different encoding.</li>
</ul></li>
<li>Would like to allow each interrupt to be configured with its privilege mode
and the &lsquo;interrupt level&rsquo; which describes the preemption level, and a
priority.</li>
<li>To manage preempted context state it&rsquo;s necessary to push/pop
mepc/mpp/mil/mie to a memory stack. You also need to remember the previous
interrupt level, &lsquo;mil&rsquo;. Now multiple levels must be tracked, which Krste
proposes could be stored in mcause.</li>
</ul>

<h2 id="risc-v-dsp-p-extension-proposal-chuan-hua-chang:d2f16b96a9dcad25ca9611e08b0e618f">RISC-V DSP (P) extension proposal: Chuan-Hua Chang</h2>

<ul>
<li>P extension task group will define and ratify a packed-SIMD DSP extension
containing instructions which operate on XLEN-bit integer registers. It will
also define compiler intrinsic functions that can be directly used in
high-level programming languages.</li>
<li>The initial proposal is based on the AndeStar V3 DSP ISA.</li>
<li>Supports e.g. 16-bit SIMD instructions with min, max, abs, compare, clip
operations. Similar for 8-bit SIMD.</li>
<li>GPR-based SIMD is more efficient for various embedded domains. It addresses
the need for high performance generic code processing as well as digital
signal processing.</li>
<li>Want to make this easy to use through intrinsic functions and optimised DSP
libraries.</li>
<li>For 64-bit data types, use pairs of GPRs on RV32. An implementation could of
course still use a 2R1W register file, but use multiple cycles to read a
64-bit value.</li>
<li>After the task group is created, bi-weekly meetings will be set up.</li>
</ul>

<h2 id="security-task-group-update-richard-newell:d2f16b96a9dcad25ca9611e08b0e618f">Security task group update: Richard Newell</h2>

<ul>
<li>The security group was previously a task group of the technical committee.
There is now a new security standing committee, at the same level with the
marketing and technical committees.</li>
<li>Task groups will be set up to look at cryptograpshic ISA extensions and
trusted execution environments for microcontroller</li>
<li>The full charter will be published on riscv.org</li>
</ul>

<h2 id="formal-assurance-for-risc-v-implementations-daniel-m-zimmerman:d2f16b96a9dcad25ca9611e08b0e618f">Formal assurance for RISC-V implementations: Daniel M. Zimmerman</h2>

<ul>
<li>Galois started with a focus on cryptography, but has broadened its scope to
&ldquo;high assurance everything&rdquo;</li>
<li>There are a range of definitions for RISC-V. The human-readable instruction
manual, mechanisations in the form of software simulators or hardware
implementations. The formal model working group have also been working on
this.</li>
<li>How can we provide assurance about these definitions / mechanisations?</li>
<li>Assurance means: the system does what it is supposed to do and doesn&rsquo;t do
anything else.</li>
<li>When trying to get assurance through compliance tests, a huge burden is put
on the shoulders of the test writers. Those conformance tests need to be 100%
complete. This also doesn&rsquo;t help determine if an implementation has
undesirable behaviours.</li>
<li>Alternatively, formally verify your system. Compile a model to RTL via
clash, then use equivalence checking tools to compare against your own
implementation.</li>
<li>Need machine-readable specification of the correctness and security of an
implementation as well as a way to measure the conformance of an
implementation.</li>
<li>How to validate a specification?

<ul>
<li>Might perform rigorous validation through execution: ad hoc testing,
simulation coverage analysis, or bisimulation.</li>
<li>Alternatively perform rigorous verification through formal reasoning:
prove test benches always pass, verification coverage analysis, or
bisimulation.</li>
</ul></li>
<li>Security properties require a different approach. They typically have a
different form, e.g. &ldquo;the following property must never hold&rdquo;. Galois is
developing a DSL that lets you specify the architecture, correctness
properties and security properties of a hardware design. It&rsquo;s also working on
a security test suite.</li>
<li>Want to help systems engineers understand and explore the effects of design
and implementation decisions on power, performance, area, and security.</li>
<li>Status

<ul>
<li>LANDO DSL is in early stages of development. Expect initial version before
2018 RISC-V summit</li>
<li>Security test suite: early stages of development</li>
<li>Metrics and measures: evaluating existing tools for PPA and looking at
existing metrics work for security</li>
<li>Dashboard: early stages of design</li>
<li>Feature model generation: early stages of design</li>
</ul></li>
</ul>

<h2 id="undefined-unspecified-non-deterministic-and-implementation-defined-behavior-in-verifiable-specifications-clifford-wolf:d2f16b96a9dcad25ca9611e08b0e618f">Undefined, Unspecified, Non-deterministic, and Implementation Defined Behavior in Verifiable Specifications: Clifford Wolf</h2>

<ul>
<li>Users of an ISA specification

<ul>
<li>Software engineers: just don&rsquo;t do anything that&rsquo;s not specified</li>
<li>Software security engineers: what can we expect from the hardware if we do
the thing that wasn&rsquo;t specified?</li>
<li>Hardware design engineers: do something safe and simple for anything not
specified. But what does safe mean?</li>
<li>Hardware verification engineers</li>
</ul></li>
<li>This presentation is a taxonomy of types of &lsquo;not specified&rsquo; behaviour, using
nomenclature taking from different domains.</li>
<li>Undefined behaviour: the &ldquo;just don&rsquo;t do that&rdquo; approach to not specifying
behaviour. The spec is void for any program as a whole if it does this
undefined behaviour once.</li>
<li>Could introduce an &lsquo;undefined value&rsquo;, but that has similar issues</li>
<li>Non-deterministic behaviour / unpredictable behaviour: allow more than one
choice, which may change under re-execution</li>
<li>Unspecified value: the instruction will return a value, but the spec doesn&rsquo;t
say which value</li>
<li>Implementation defined behaviour / value: similar to unspecified value /
behaviour, but the implementer must specify what it is.</li>
<li>Fully specified behaviour: the ideal choice for verification. Explicitly
state what all implementations must do.</li>
<li>Clifford strongly prefers implementation defined or fully specified
behaviour.</li>
</ul>

<h2 id="foundational-hpc-systems-in-2020-and-beyond-steven-wallach:d2f16b96a9dcad25ca9611e08b0e618f">Foundational HPC systems in 2020 and beyond: Steven Wallach</h2>

<ul>
<li>Architecture 1.0 (see Mark Hill paper). The world was very
processor-centric. CPUs with memory attached.</li>
<li>Architecture 2.0. Not just the ISA. Move towards memory-driven computing.

<ul>
<li>Numerical processing is trivial, but achieving efficient memory access is
very hard.</li>
<li>Caches now need to be protected machine state.</li>
</ul></li>
<li>An RV128 working group is going to be started, chaired by Steven

<ul>
<li>Propose a 64-bit object ID and 64-bit byte offset.</li>
</ul></li>
<li>On an RV128 system, have to be able to execute RV64 programs and map 64-bit
virtual into 128-bit virtual. Also map system calls.</li>
<li>Object 0 is kernel object, object 1 RV64, object 2 RV32.</li>
<li>Encrypted memory is identified with an object ID</li>
<li>Steven suggests disabling speculation if kernel objects are referenced.</li>
</ul>

<h2 id="european-processor-initiative-and-risc-v-mateo-valero:d2f16b96a9dcad25ca9611e08b0e618f">European processor initiative and RISC-V: Mateo Valero</h2>

<ul>
<li>BSC-CNS is a consortium including the Spanish government, Catalan
government, and UPC</li>
<li>Now have 529 people from a wide range of countries.</li>
<li>Need to reach 50GFlops/W</li>
<li>MareNostrum 4 has been recognised as the &ldquo;most beautiful datacenter in the
world&rdquo;. Total peak performance is 13.7 PFlops</li>
<li>USA, Japan, China are all building huge supercomputers with domestic
technology. Can the EU do the same?</li>
<li>The EU has a large HPC ecosystem and a number of centers of excellence in
HPC applications.</li>
<li>Through the Mont Blanc project, proposed the use of ARM processors in
supercomputing applications. Extended current mobile chips with HPC features.</li>
<li>Europe has only 4 machines in the world top 20.</li>
<li>With Brexit and Softbank, ARM is not &lsquo;European&rsquo; any more.</li>
<li>Through EuroHPC, the Commission has proposed to invest 1B.</li>
<li>The European Processor Initiative is a consortium consisting of 23 partners.
They will form the company &lsquo;EPI Semiconductor&rsquo; which will produce the EPI
common platform. Now looking at growing the consortium, including companies
from other countries.</li>
<li>Three streams

<ul>
<li>General purpose and common platform. ARM SVE or other candidates. BULL
will be system integrator / chip integrator.</li>
<li>Accelerator: RISC-V</li>
<li>Automotive</li>
</ul></li>
<li>RISC-V accelerator vision: throughput-oriented designs, lower power,
supporting MPI+OpenMP</li>
</ul>

<h2 id="securing-high-performance-risc-v-processors-from-time-speculation-chris-celio:d2f16b96a9dcad25ca9611e08b0e618f">Securing High-performance RISC-V Processors from Time Speculation: Chris Celio</h2>

<ul>
<li>Meltdown and Spectre don&rsquo;t just impact a single processor design or a single
company&rsquo;s design, but really impact any CPU using speculation.</li>
<li>A timing attack is when a change in your program input affects the time of
another user.</li>
<li>There are 3 parts to a timing attack

<ul>
<li>Victim runs code that leaks observable side effects</li>
<li>Attacker runs code affected by timing leaks</li>
<li>Attacker measures time his code took to run</li>
</ul></li>
<li>Chris built up a taxonomy of time leaks. Two axes: were are we leaking from,
and what are we directly leaking.</li>
<li>High level ideas:

<ul>
<li>Don&rsquo;t leak any observable side-effects in the machine if speculation is
aborted</li>
<li>Avoid bandwidth interference between different time domains. Depending on
the time domain you care about, this could be bandwidth to a functional
unit.</li>
</ul></li>
<li>Modern speculative cores have 100-300 instructions in-flight, but not all
are speculative. About 25% are beyond the point of non-return.</li>
<li>Idea: do not update predictors speculatively.</li>
<li>Idea: Don&rsquo;t speculatively update the cache. Could get rid of fully inclusive
L1/L2/L3 caches in favour of neither exclusive nor inclusive (NENI) caches.
Then allocate only into the L1 cache.</li>
<li>Idea: misspeculation recovery should be deterministic. Any shared resource
can leak time</li>
<li>Idea: partition caches etc</li>
<li>Idea: dynamic partitioning</li>
<li>Idea: partial and full flushes. e.g. flush <sup>1</sup>&frasl;<sub>4</sub> BTB entries.</li>
<li>Many other ideas (see the full list in the slides!)</li>
</ul>

<h2 id="evaluation-of-risc-v-for-pixel-visual-core-matt-cockrell:d2f16b96a9dcad25ca9611e08b0e618f">Evaluation of RISC-V for Pixel Visual Core: Matt Cockrell</h2>

<ul>
<li>Background: the Pixel Visual Core is a Google-design Image Processing Unit
(IPU). It has a dedicated A53 which aggregates application layer IPU resource
requests.</li>
<li>Looking at adding a microcontroller as a job scheduling and dispatch unit.</li>
<li>When selecting a core, key considerations were: level of effort (how
difficult to integrate), risk (stability and reliability of support), and
license.</li>
<li>First candidate was the internal &lsquo;Bottle Rocket&rsquo; project. This implements
RV32IMC, reusing parts of the Rocket design. High level of effort, medium
risk.</li>
<li>Second candidate: Merlin (github.com/origintfj/riscv). Low level of effort,
high risk.</li>
<li>Third candidate: RI5CY, produced by the PULP team. Low level of effort,
medium risk.</li>
<li>Selected RI5CY for a number of reasons: it had been taped out, had good
infrastructure, the license was acceptable, and it was implemented in
SystemVerilog rather than Chisel.</li>
<li>Why SystemVerilog rather than Chisel?

<ul>
<li>SystemVerilog builds on established physical design and verification flows</li>
<li>Chisel generated verilog loses designer&rsquo;s intent, making it difficult to
read and debug</li>
<li>Chisel generated code makes certain physical design items difficult such
as sync/asnc clocks, power domains, clock domains etc</li>
</ul></li>
<li>Next steps: add full compliance for privilege/debug specification and
evaluate performance impact after adding RI5CY to the Pixel Visual Core.</li>
</ul>

<h2 id="linux-ready-rv-gc-andescore-with-architecture-extensions-charlie-su:d2f16b96a9dcad25ca9611e08b0e618f">Linux-Ready RV-GC AndesCore with Architecture Extensions: Charlie Su</h2>

<ul>
<li>The AndeStar V5 architecture adopts RISC-V and adds pre-defined useful Andes
extensions as well as custom-extension frameworks for domain-specific
acceleration.</li>
<li>Baseline extension instructions

<ul>
<li>Memory access and branches with fewer instructions</li>
<li>Code size reduction on top of C extension (&lsquo;CoDense&rsquo;)</li>
<li>DSP/SIMD (see P extension proposal)</li>
<li>Custom instructions</li>
<li>CSR-based extensions that don&rsquo;t require new instructions. e.g. stack
protection mechanism, power management, &hellip;</li>
</ul></li>
<li>Delivered 32-bit and 64-bit implementations of the V5 architecture
implementation AndeStar V5m which is a superset of RV-IMAC.</li>
<li>An N25 (32-bit) small configuration is 37k gates at 28HPC, 1GHz. Large
configuration is 159k gates.</li>
<li>Introducing new 25-series cores adding floating point support (N25F/NX25F),
MMU, and S mode (A25/AX25).</li>
<li>3.49CM/MHz</li>
<li>Added hit under miss caches and hardware support for misaligned accesses</li>
<li>Use single-port SRAMs to reduce area and power</li>
<li>COPILOT tool allows auto-generation of development tools for a set of custom
extensions.</li>
<li>Software

<ul>
<li>Worked with Express Logic to port 64-bit ThreadX</li>
<li>Added support for AX25 to QEMU</li>
<li>Working on adding further component support for Linux: u-boot, ftrace,
loadable modules, Linux perf.</li>
</ul></li>
<li>openSUSE is helping to enable their &lsquo;EBBR&rsquo; specification for RISC-V</li>
</ul>

<h2 id="processor-trace-in-a-holistic-world-gajinder-panesar:d2f16b96a9dcad25ca9611e08b0e618f">Processor trace in a holistic world: Gajinder Panesar</h2>

<ul>
<li>Understanding program behaviour in complex system isn&rsquo;t easy, and using a
debugger isn&rsquo;t always possible. Processor Branch Trace can provide visibility
into program execution.</li>
<li>Processor Branch Trace works by tracking execution from a known start
address and sending messages about the deltas taking by the program. For
uncoditional branches, there is no need to report the destination address.</li>
<li>The trace encoder ingress port defines singles to export from the processor.
It contains information such as the privilege mode, address of the
instruction, the instruction.</li>
<li>The trace encoer sends a packet which could contain a delta update with a
subset of information, or a full context to force synchronisation.</li>
<li>Trace control can control when a trace is generated, or configure filters.</li>
<li>Saw a mean 0.252 bits/instruction encoding efficiency across a range of
benchmarks.</li>
<li>Next steps: set up task group to standardise processor to encoder interface
and a compressed branch trace format</li>
</ul>

<h2 id="risc-v-meets-22fdx-an-open-source-ultra-low-power-microcontroller-for-advanced-fdsoi-technologies-pasquale-schiavone-and-sanjay-charagulla:d2f16b96a9dcad25ca9611e08b0e618f">RISC-V meets 22FDX. An open source ultra-low power microcontroller for advanced FDSOI technologies: Pasquale Schiavone and Sanjay Charagulla</h2>

<ul>
<li>PULP was design for near sensor (aka edge) processing.</li>
<li>Seen a range of contributions since open sourcing from e.g. Embecosm,
lowRISC, Micron, Google, &hellip;</li>
<li>PULPissimo has a rich set of peripherals: QSPI, HyperRam+HyperFlash, camera
interface, I2C, I2S, JTAG, &hellip; Plus an autonomous IO DMA subsystem (uDMA)</li>
<li>Implements an efficient low-latency interconnect.</li>
<li>Used a RI5CY core plus extensions: packed SIMD, fixed point, bit
manipulation, hardware loops. Included a IEEE 754 single precision floating
point unit.</li>
<li>2.3mm2, effective area 1.22mm2. Most of the area taken by memories.</li>
<li>40MOPS/mW at 350MOPS. 1.4x better performance and 4x better energy
efficiency than previous design in 40nm</li>
<li>Can further reduce power to 65MOPS/mw at 350MOPS when executing just from
SCM.</li>
<li>Global Foundries produce up to 10M wafers / year (200mm equivalents)</li>
<li>GF has a dual-track roadmap. Performance optimized FinFET and power
optimized FD-SOI.</li>
<li>FDXcelerator is accelerating RISC-V developers and partners. Partners
include SiFive, Andes, Reduced Energy Microsystems, &hellip;</li>
<li>This is the first step towards silicon-qualified free-open-source RISC-V IPs
on GF FDX22 process</li>
</ul>

<h2 id="ariane-an-open-source-64-bit-risc-v-application-class-processor-and-latest-improvements-florian-zaruba:d2f16b96a9dcad25ca9611e08b0e618f">Ariane. An Open-Source 64-bit RISC-V Application Class Processor and latest improvements: Florian Zaruba</h2>

<ul>
<li>Ariane is a Linux-capable 64-bit core</li>
<li>M, S, U privilege modes. TLB. Tightly integrated D$ and I$, hardware page
table walker</li>
<li>Area around 185kGE</li>
<li>Greater than 1.5GHz at 22FDX</li>
<li>Critical path is 25 logic levels</li>
<li>6 stage pipeline. In-order issue, out-of-order writeback, in-order commit</li>
<li>Why develop another core?

<ul>
<li>Don&rsquo;t want an SoC generator. Don&rsquo;t want to be governed by a 3rd party</li>
</ul></li>
<li>First implementation took about 4 months</li>
<li>Designed for higher performance in the future: dual issue and/or OoO issue</li>
<li>Verification strategy

<ul>
<li>RISC-V tests</li>
<li>Torture test framework</li>
<li>Running applications on FPGA e.g. bootling Linux</li>
<li>Verification isn&rsquo;t exhaustive, looking into more alternatives</li>
</ul></li>
<li>Ariane was open-sourced in February 2018. Already seen non-trivial external
contributions.</li>
<li>Latest improvements:

<ul>
<li>Completely revised instruction frontend.</li>
<li>Re-naming in issue stage</li>
</ul></li>
<li>Return address stack cost ~1KGE, improves IPC by 20%. Resolving
unconditional jumps immediately increases IPC by ~11%. These changes had no
negative impact on timing.</li>
<li>Critical paths are on the memory interfaces, especially tag compare and
address translation for cache access.</li>
<li>Kerbin is a proof of concept SoC for Ariane featuring PULP peripherals, a
64-bit interconnect and debug support.</li>
<li>Compatible with gdb, but require a debug bridge currently.</li>
<li>Managed to boot Linux after 5 months development</li>
<li>FPGA: Targeted the VC707. Core runs at 50-100MHz, 15kLUTs.</li>
<li>Ariane has been taped out in GF22FDX. 910MHz, &hellip;</li>
<li>Working on Kosmodrom tapeout which includes a high performance and a low
power version and a floating point accelerator.</li>
<li>Working on supporting F and D extensions as well as reduced prevision vector
operations. Stand-alone floating point unit (~200kGE) will be released in the
next months.</li>
<li>Also working on improved integer divider, vector unit, and hardware support
for atomic memory operations</li>
<li>Help wanted: support for official RISC-V debug, improved branch predictors,
multithreading, cache-coherent interconnect, &hellip;</li>
</ul>

<h2 id="risc-v-support-for-persistent-memory-systems-matheus-ogleari:d2f16b96a9dcad25ca9611e08b0e618f">RISC-V support for persistent memory systems: Matheus Ogleari</h2>

<ul>
<li>(Missed the first few minutes I&rsquo;m afraid)</li>
<li>RISC-V changes: introduce new instructions. ucst (uncacheable write to
memory), ucld (uncacheable read from memory)</li>
<li>Also modify the cache controller and memory controller</li>
<li>These changes would enable new applications. Even defining the instructions
would allow people to start work using software simulation tools.</li>
</ul>

<h2 id="the-hybrid-threading-processor-for-sparse-data-kernels-tony-brewer:d2f16b96a9dcad25ca9611e08b0e618f">The hybrid threading processor for sparse data kernels: Tony Brewer</h2>

<ul>
<li>Sparse data sets that greatly exceed a processor&rsquo;s cache size are a
challenge for most systems. The cache hit rate is low resulting in idle cores.</li>
<li>The Hybrid Threading Processor defines extensions for thread and message
management. It&rsquo;s a high thread count barrel processor similar to Cray&rsquo;s MTA
architecture.

<ul>
<li>Software-managed coherency</li>
<li>Event driven processor.</li>
</ul></li>
<li>Can perform atomic operations at memory due to the software-managed
coherency</li>
<li>The project was funded under the DARPA CHIPS project. This produced two
chiplets: the memory controller (MC) chiplet and compute near memory (CNM)
chiplet.</li>
<li>Implemented a simulator modelling functionality and performance, and also
performed power estimation.</li>
<li>Performed a sensitivity analysis to determine the optimal configuration.</li>
<li>Compared performance for graph spectral clustering vs Haswell, Nvidia K80,
Nvidia DGX-1. Saw ~25x better energy efficiency.</li>
</ul>

<h2 id="how-pulp-based-platforms-are-helping-security-research-frank-gurkaynak:d2f16b96a9dcad25ca9611e08b0e618f">How PULP-based platforms are helping security research: Frank Gurkaynak</h2>

<ul>
<li>Security of the system is not limited to just &ldquo;one part&rdquo;. You need to
consider the entire system</li>
<li>An open approach has proven useful for security in software. Why should
hardware be any different?</li>
<li>Cryptographic accelerators can easily achieve high throughput with low area.</li>
<li>PULP provides multiple opportunities to add extensions. e.g. new
instructions added directly to the core, adding peripherals to the bus, or
hardware accelerators with direct memory access</li>
<li>Implemented Fulmine, an IoT processor with accelerators. Added two TCDM
ports, 64bits/cycle. The AES unit performs 2 rounds a cycle, 1.76Gbit/s and
120pJ per byte (entire chip) at 0.8V and 84MHz</li>
<li>Side channel attacks are a huge challenge. Recently implemented a leakage
resilient accelerator which reduces the attack surface by generating a new key
per data block. This provides 5.29Gbit/s throughput at 256Mhz</li>
<li>Attacks that target control flow are a serious problem and can be realized
in both hardware (e.g. glitching) or software. Implemented and published
sponge based control-flow protection (SCFP), which stores instructions
encrypted in memory. As instructions must be decrypted, the attacker would
have to modify both the instruction and the internal state.

<ul>
<li>Implemented in Patronus chip. 25-35% power/area overhead, and 10$ runtime
overhead due to &lsquo;patches&rsquo; and additional commands.</li>
<li>The probability of an illegal instruction trap when an instruction altered
is 91.51% within 1 cycle rising to 99.95% within 3 cycles.</li>
</ul></li>
</ul>

<h2 id="risc-v-virtual-platforms-for-early-risc-v-embedded-software-development-kevin-mcdermott:d2f16b96a9dcad25ca9611e08b0e618f">RISC-V virtual platforms for early RISC-V embedded software development: Kevin McDermott</h2>

<ul>
<li>New markets have new software requirements</li>
<li>Virtual platforms can help accelerate software development</li>
<li>Imperas produce extendable platform kits (EPKs). These are virtual platforms
with software set-up, allowing users to start quickly.</li>
<li>Offer the ability to easily define custom instruction extensions</li>
<li>Can also perform software development using the Ashling RISC-V IDE</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>Barcelona RISC-V Workshop: Day One</title><link>https://www.lowrisc.org/blog/2018/05/barcelona-risc-v-workshop-day-one/</link><guid>https://www.lowrisc.org/blog/2018/05/barcelona-risc-v-workshop-day-one/</guid><pubDate>Tue, 08 May 2018 07:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2018/04/risc-v-workshop-in-barcelona-agenda/">eighth RISC-V
workshop</a> is
going
on today in Barcleona. As usual, I&rsquo;ll be keeping a semi-live blog of talks and
announcements throughout the day.</p>

<p>Follow <a href="https://www.lowrisc.org/blog/2018/05/barcelona-risc-v-workshop-day-two/">here</a> for the
day two live blog.</p>

<p>Note that slides from most presentations are now <a href="https://riscv.org/2018/05/risc-v-workshop-in-barcelona-proceedings/">available at
riscv.org</a>.</p>

<h2 id="introduction-rick-o-connor:2362d622cd60bdb9d5eb8a1222aae504">Introduction: Rick O&rsquo;Connor</h2>

<ul>
<li>This workshop has 325 attendees representing 101 companies and 25
universties. Largest outside of Silicon Valley.</li>
<li>Rick gives the usual overview of the RISC-V Foundation structure.</li>
<li>The RISC-V Foundation currently has over 150 members, including invidual
members. These members are distributed across 25 countries around the world.</li>
</ul>

<h2 id="risc-v-state-of-the-union-krste-asanovic:2362d622cd60bdb9d5eb8a1222aae504">RISC-V state of the union: Krste Asanovic</h2>

<ul>
<li>Krste gives an overview of the RISC-V ISA for newcomers.</li>
<li>RISC-V encoding terminology.

<ul>
<li>Standard: defined by the Foundation</li>
<li>Reserved: Foundation might eventually use this space for future standard
extensions.</li>
<li>Custom: Space for impelmenter-specific extensions, never claimed by
Foundation.</li>
</ul></li>
<li>The RISC-V big tent philosophy: enable all types of RISC-V implementation,
from 32-bit microcontrollers with 1KiB SRAM up to 64-bit Unix servers with
virtualisation or 128-bit 100k-core supercomputer with PiBs DRAM, open or
proprietary business models, non-conforming extensions, software
implementations (e.g. QEMU), &hellip;

<ul>
<li>Minimize wasted work through maximum reuse. Factor out platform-level
requirements from reusable ISA and software modules</li>
<li>Use standard platform profiles to reduce ecosystem effort.</li>
</ul></li>
<li>A system is minimally RISC-V-ISA-compliant if it runs claimed RISC-V
unprivileged code correctly. e.g. gcc-compiled RV32IMAC functions work
correctly. Platform must support loading program, returning result etc.</li>
<li>One set of unprivileged ISA compliance tests should be able to run on any
platform. There is a challenge here in handling tiny platforms, e.g. 1KiB
SRAM.</li>
<li>A platform specification provides tight constraints on system configuration
and options to support a software ecosystem.

<ul>
<li>It provides an interface between platform hardware and software, including
privileged levels.</li>
<li>Avoid unnecessary duplication. Where it&rsquo;s possible to define a common
standard, do so.</li>
<li>Platform compliance tests will be built in collaboration with the relevant
ecosystem. e.g. server platform compliance, ZephyrOS platform compliance.</li>
</ul></li>
<li>Software is king in the RISC-V land

<ul>
<li>ISA extensions need compiler/linker/library support</li>
<li>There&rsquo;s no point adding instructions if no software wants to use it.</li>
<li>ISA proposals should be sensible to implement.</li>
<li>Finished now is better than perfect sometime. But at the same time,
shouldn&rsquo;t rush to freeze a spec before it&rsquo;s ready.</li>
</ul></li>
<li>Open-source hardware vs software

<ul>
<li>Some lessons from the free/open source software community apply, but many
things are different. e.g. very large investments in hardware that cannot be
changed once manufactured, threat of patent lawsuits</li>
</ul></li>
<li>Major milestones in 2017

<ul>
<li>Fixed holes in user ISA, no changed now in IMAFDQC</li>
<li>Froze priv-1.10 spec. Updates must be backwards compatible</li>
<li>Memory model work</li>
<li>Linux ABI frozen</li>
<li>Debug spec completed</li>
</ul></li>
<li>2018 initiatives

<ul>
<li>Working to prepare the base ISA for ratifications</li>
<li>Formal spec in progress</li>
<li>Hypervisor spec done, need implementations</li>
<li>Crypto in progress</li>
<li>J (dynamic translation / runtimes) in progress</li>
<li>Packed SIMD in progress</li>
<li>Security task group ongoing</li>
<li>Fast interrupts started</li>
<li>Trace started</li>
<li>Krste comments it may take longer to finish these things vs comparable
industry projects.  Have many more stakeholders giving input.</li>
</ul></li>
<li>2018 embedded platform

<ul>
<li>New ABI for embedded (e.g. long double = 64bit)</li>
<li>Build on RV32E</li>
<li>compiler/library work for improved code compression</li>
</ul></li>
<li>RISC-V and security

<ul>
<li>Set up security standing committee. Chaired by Helena Handschuh (Rambus),
vice-chair Joe Kiniry (Galois Research).</li>
</ul></li>
</ul>

<h2 id="the-state-of-risc-v-software-palmer-dabbelt:2362d622cd60bdb9d5eb8a1222aae504">The state of RISC-V software: Palmer Dabbelt</h2>

<ul>
<li>Palmer shows a picture of Xorg with web browser, terminal, webcam, and a 3d
video game all running on a RISC-V core (SiFive Unleashed with Microsemi
add-on board).</li>
<li>GNU-based toolchains

<ul>
<li>binutils, gcc, glibc, newlib all upstreamed.</li>
</ul></li>
<li>The RISC-V Linux kernel port was upstreamed in January 2018. It only
supports RV64I systems for now, and is currently missing some platform
drivers. Help would be welcomed in getting these upstream.</li>
<li>RISC-V Fedora and Debian support is in progress</li>
<li>RISC-V LLVM port is making rapid progress. RV32IMFDC upstream. [As a
correction to the talk, compressed support is upstream - thanks to
contributions from Andes Tech and Qualcomm!]</li>
<li>Bootloaders: U-boot is upstream, TianoCore is a work in progress. Coreboot
RISC-V support is upstream but a little out of date. UEFI standard process is
ongoing.</li>
<li>Embedded runtimes: Zephry is upstream, seL4 upstream, FreeRTOS exists but
isn&rsquo;t upstream, Micrium uC/OS is available, as is ThreadX.</li>
<li>Debugging: GDB port upstream, OpenOCD exists but not upstream. Also
commercial debuggers: Segger, Lauterbach, UltraSoC, IAR is upcoming.</li>
<li>The core software stack has been supported by a consortium of developers
from a range of companies.</li>
<li>RISC-V software implementations: Spike, RV8, Renode, QEMU (upstreamed and
included in a upstream release about a week ago)</li>
<li>There are also commercial simulators, such as Imperas OVP and Esperanto&rsquo;s
simulator.</li>
<li>Help wanted: OpenJDK JIT port, Arduino runtime</li>
<li>The RISC-V platform specification working group will define profiles for
types of RISC-V systems. e.g. bare-metal embedded, RTOS, embedded Linux,
portable Linux.</li>
</ul>

<h2 id="the-risc-v-vector-isa-update-roger-espassa:2362d622cd60bdb9d5eb8a1222aae504">The RISC-V vector ISA update: Roger Espassa</h2>

<ul>
<li>The spec isn&rsquo;t yet ready&hellip;but it&rsquo;s getting really close</li>
<li>Updates and discussion points:

<ul>
<li>Register types moved to an extension.</li>
<li>Widening multiplies</li>
<li>Debating whether reductions should be in base or not</li>
<li>Worked on overlaying V-reg and F-reg to save state, decided against it</li>
<li>Fixed point vclip instructions</li>
<li>Mask support for speculative vectorisation</li>
<li>Possibility to fit integer MADD within encoding</li>
</ul></li>
<li>Scalar support: the encoding allows indicating that the destination vreg is
a &ldquo;scalar shape&rdquo;. Introduce VLO/VSO to load/store single scalar elements.</li>
<li>Roger is outlining the newly introduced instructions. I can&rsquo;t usefully
summarise these, so you&rsquo;re best waiting for the slides to be published.</li>
<li>vclip is introduced to help support fixed point.</li>
<li>FP16 operations are introduced and are required for the V extension.</li>
<li>The vector extension introduces interesting instructions such as vector-fpr
merge, vector-fp merge, slide down / slide up</li>
<li>Plan to close the base spec very soon</li>
<li>Want to see compiler output before bringing for ratification</li>
<li>Haven&rsquo;t yet started on formal spec for the vector ISA</li>
</ul>

<h2 id="the-isa-formal-spec-technical-update-rishiyur-nikhil:2362d622cd60bdb9d5eb8a1222aae504">The ISA formal spec technical update: Rishiyur Nikhil</h2>

<ul>
<li>What what use is an ISA formal spec?

<ul>
<li>Answer questions about compiler correctness. Will executing a certain two
C programs produce the same results? For all inputs? For all C and
corresponding RISC-V programs?</li>
<li>Answer questions on implementation correctness. Will executing this progam
produce correct results? On all RISC-V processors?</li>
</ul></li>
<li>ISA formal spec goals

<ul>
<li>Clear and understandable to the human reader. Precise and complete.
Machine readable. Executable (run RISC-V programs, boot an OS). Usable with
various formal tools.</li>
</ul></li>
<li>Key issues

<ul>
<li>RISC-V&rsquo;s modularity. A wide range of options, some of which are
dynamically selectable or can vary between privilege levels. The spec needs
to capture all combinations and still remain readable.</li>
<li>Extensibility. Want to allow people to build upon the formal spec to add
support their own extensions.</li>
<li>Non-detterminism and concurrency.</li>
</ul></li>
<li>Status. Various approaches are being pursued: 3 projects in Haskell, 1
project in SAIL, 1 project in L3, another in a &lsquo;functional subset&rsquo; of Verilog

<ul>
<li>One of the Haskell projects (led by a team at MIT) is furthest along.
Models RV32I, RV64I, M, priv U+S+M, Sv39 VM</li>
</ul></li>
<li>Next steps: within a couple of months publish a formal spec that is complete
for RV32IMAC, RV64IMAC, user+supervisor+machine mode, sv32+sv39, and a simple
sequential memory model. Liaise with the compliance group to use the formal
spec as a golden reference for compliance suites. Then work to integrate with
the weak memory model.</li>
<li>Potential follow-up projects (by community?)

<ul>
<li>Formally show equivalences between different ISA formalisations</li>
<li>Demonstrate extensibility to other standard options (e.g. vector, crypto)</li>
<li>Use it! (to provide correctness of hardware implementations, compilers,
&hellip;)</li>
</ul></li>
</ul>

<h2 id="risc-v-memory-consistency-model-status-update-dan-lustig:2362d622cd60bdb9d5eb8a1222aae504">RISC-V memory consistency model status update: Dan Lustig</h2>

<ul>
<li>The specification is released for public comment, which will run through to
June 16th.</li>
<li>Fundamentally, the RISC-V memory consistency model specifies the values that
can be returned by loads.</li>
<li>The RISC-V memory model specification defines the RISC-V weak memory
ordering (RVWMO) model and extensions: Zam (misaligned atomics), Ztso (Total
Store Ordering).</li>
<li>Global memory order (GMO): a total order over the memory operations
generated by the instructions in each program</li>
<li>GMO is constrained by the Preserved Program Order (PPO)</li>
<li>Load Value Axiom</li>
<li>Atomicity Axiom: no store from another hart can appear in the global memory
order between a paired LR and successful SC (see spec for full details of
rule)</li>
<li>Progress Axiom: no memory operation may be preceded in the global memory
order by an infinite sequence of other memory operations</li>
<li>Misaligned AMOs are not supported in the base &lsquo;A&rsquo; extension, but can be
supported with the &lsquo;Zam&rsquo; extension.</li>
<li>Ztso strengthens the baseline memory model to TSO, but TSO-only code is not
backwards-compatible with RVWMO.</li>
<li>Authored two appendices which give lengthy explanations in plain English as
well as axiomatic and operational models. More than 7000 litmus tests are
available online.</li>
<li>Ongoing/future work

<ul>
<li>Mixed-size, partially overlappy memory accesses</li>
<li>Instruction fetches and fence.i, TL flushes and sfence.vma etc</li>
<li>Integrations with V, J, N, T extensions</li>
<li>&hellip;</li>
</ul></li>
</ul>

<h2 id="software-drives-hardware-lessons-learned-and-future-directions-robert-oshana:2362d622cd60bdb9d5eb8a1222aae504">Software drives hardware. Lessons learned and future directions: Robert Oshana</h2>

<ul>
<li>Software engineers can innovate earlier/often and drive more specific core
requirements for hardware design team</li>
<li>Software engineers like to dream of a simple single core running at very
high clock rate, and zero latency unlimited bandwidth access to a single
memory. A hardware engineers dreams of many cores at 1ghz with accelerators,
separate memories etc.</li>
<li>Trying to achieve even faster development cycles.</li>
<li>Start with system modelling, move to system definition, and produce
intrinsic libraries, new instructions, programming model details, and a Chisel
model.</li>
<li>Moving towards &ldquo;software driven hardware&rdquo; to support the software
programming model (2020).</li>
<li>NXP are using PULPino.</li>
<li>Challenge: establishing a robust open community for RISC-V. Want to see
multiple vendors contributing back to the &lsquo;RISC-V ISA mainline&rsquo;.</li>
<li>Using RISC-V mainly as &lsquo;minion cores&rsquo;. Focused on efficient core designs and
ISA enhancement for application-specific functionality. e.g. bit manipulation,
crypto. Other innovation targets include a multi RISC-V core MCU SoC.</li>
<li>Embedded software engineers will take a bigger role in defining the SoC
architecture

<ul>
<li>Programming model</li>
<li>System optimsiation</li>
</ul></li>
<li>Open source RISC-V implementations will allow more software driven hardware.
Ecosystem is vital to success.</li>
</ul>

<h2 id="unleashing-the-power-of-data-with-risc-v-martin-fink:2362d622cd60bdb9d5eb8a1222aae504">Unleashing the power of data with RISC-V: Martin Fink</h2>

<ul>
<li>Why has Western Digital made such a big commitment to RISC-V even though
they&rsquo;re not in the processor business? Feel there&rsquo;s too much focus on the CPU,
when the focus needs to be on the data.</li>
<li>Half the world&rsquo;s data lives on Western Digital devices.</li>
<li>First Western Digital RISC-V core. 2-way superscalar, mostly in-order core
with 9 stage pipeline. RV32IMC, 1 load/store pipe, 1 multiplier, 1 divider, 4
ALU engines.

<ul>
<li>Performance targets at 28nm. Dhrystone greater than 2MIPS/Mhz, CoreMark
over 3 CM/MH. 1GHz operation.</li>
<li>Built to show it can be done and better understand RISC-V</li>
<li>Most of the work went into the uncore.</li>
</ul></li>
<li>Produced a NAND controller SoC using RISC-V. Added instruction optimisations
for NAND media handling.</li>
<li>Still on track to ship first products with RISC-V in 2019.</li>
<li>RISC-V in embedded

<ul>
<li>Free and open IP connectivity buses enabling plug and play of proprietary
and open source IPs</li>
</ul></li>
<li>RISC-V in enterprise

<ul>
<li>Datacenter CPUs with smart, fast and open peripheral buses enable new
compute paradigms for AI workloads</li>
</ul></li>
<li>General purpose architectures are no longer sufficient. Workload diversity
demands diverse technologies and architectures.</li>
<li>Open source software licenses can apply to HDL, GDSII, Gerber. There is more
work still needed though.</li>
<li>Strong believer in the GPLv2. The troubling part about permissive licensing
is it allows people to do proprietary things without sharing. Pragmatically,
many companies gravitate towards permissive licenses like Apache. Hope to move
work word towards copyleft over time.</li>
<li>Western Digital is working to support development of open source IP building
blocks for the community. Will actively partner and invest in the ecosystem.
Accelerate development of purpose-built processors for a broad range of Big
Data and Fast Data environments.</li>
<li>There is a multi-year transition of Western Digital devices, platforms and
systems to RISC-V.</li>
<li>Question from the audience: will Western Digital be open sourcing their
cores? Would like to, but not making a commitment today. One of the challenges
is uncoupling from the uncore. Ultimately hope to share cores and IP blocks.</li>
</ul>

<h2 id="risc-v-debugging-custom-isa-extensions-multicore-dtm-variants-markus-goehrle:2362d622cd60bdb9d5eb8a1222aae504">RISC-V debugging. Custom ISA extensions, multicore, DTM variants: Markus Goehrle</h2>

<ul>
<li>Support for a variety of external and internal interfaces, as well as
interconnections of standard debug transport modules (DTM).</li>
<li>TRACE32 has Linux-awareness, including the ability to view resources such as
task and kernel modules, addresses of dynamic objects etc.</li>
<li>Support heterogeneous systems, custom ISA extensions</li>
<li>Found that a lot of customers have built something based on the draft debug
specification, as well as others who implement their own custom debug IP.
People are also doing custom solutions for trace. The speaker strongly urges
people to feed into the debug specification standardisation process.</li>
</ul>

<h2 id="gdb-for-risc-v-jeremy-bennett:2362d622cd60bdb9d5eb8a1222aae504">GDB for RISC-V: Jeremy Bennett</h2>

<ul>
<li>GDB support was committed upstream as of early March, including basic bare
metal support. This sees nightly regression tests with a pass rate above 99%.</li>
<li>Next steps include:

<ul>
<li>XML target description support</li>
<li>Memory map support</li>
<li>Remote I/O support</li>
<li>Adding non-DWARF stack unwinding</li>
<li>Upstreaming a GDB Simulator</li>
<li>Linux application debugging</li>
</ul></li>
<li>GDB support for multicore debug is evolving, with support for multiple
active inferiors with their own flow of control and address space. Each
inferior is associated with a program space (symbol table and DWARF debug
information) for the code running on that inferior.</li>
<li>Upstream GDB supports multiple concurrent inferiors which has been tested
for RISC-V with a 36-core system. More work is needed for complex address
spaces (e.g. where some memory is shared with other inferiors).</li>
</ul>

<h2 id="a-common-software-development-environment-for-many-core-risc-v-hardware-and-virtual-platforms-gajinder-panessar-and-simon-davidmann:2362d622cd60bdb9d5eb8a1222aae504">A common software development environment for many-core RISC-V hardware and virtual platforms: Gajinder Panessar and Simon Davidmann</h2>

<ul>
<li>Talking today about a collaboration between Imperas and UltraSoC to provide
a common environment for debugging simulation-based and hardware debug.</li>
<li>Chip designs are getting more complex, including asymmetric multi-core.</li>
<li>Embedded software is increasingly important and engineering intensive.</li>
<li>Traditionally use GDB, with one instance per core. This has little
visibility as it only sees the memory space of the attached CPU. It also gives
poor control, and bugs may occur non-deterministically.</li>
<li>Imperas provide a commercial simulation solution, running at 100-2000MIPS.

<ul>
<li>This suports the Imperas &lsquo;MPD&rsquo; full platform debugger.</li>
</ul></li>
<li>UltraSoC provide IP for debug/monitoring for the whole SoC</li>
<li>Imperas and UltraSoC have collaborated to provide a common solution.</li>
</ul>

<h2 id="hifive-unleashed-world-s-first-multi-core-risc-v-linux-dev-board-yunsup-lee:2362d622cd60bdb9d5eb8a1222aae504">HiFive unleashed. World&rsquo;s First Multi-Core RISC-V Linux Dev Board: Yunsup Lee</h2>

<ul>
<li>When Instagram was acquired for $1B it has just 13 engineers. They achieved
that partially by reusing open source software.</li>
<li>See SiFive silicon cloud services as a parallel to Amazon AWS. Offers a
selection of CPU soft IPs, prototype ASICs, production ASICs.</li>
<li>Talking today about the Freedom Unleashed platform. Features 4 application
cores and 1 embedded core.</li>
<li>The HiFive Unleashed board feature an SiFive FU540-C000, 8GB DDR4, Gigabit
Ethernet port, 32MB Quad SPI flash, microSD card for removable storage,
MicroUSB for debug and serial communication, digital GPIO pins, FMC connector.</li>
<li>Did a preliminary SPECINT2006 comparison. Competitive with A53 chips from
Rockchip or Alwinner (higher than the lower-clocked Allwinner, but slower than
the Rockchip).</li>
<li>Open-V: a SiFive/ONCHIP microcontroller based on Freedom Everywhere. Built
in TSMC 180nm, 3.3mm x 2.6mm. 2.7M transistors. ONCHIP provided a range of
analog IP, which were integrated with a SiFive E31 core. The components will
be available through SiFive.</li>
<li>You can now submit proposals for your own freedom chip through the
&ldquo;Democratizing Ideas&rdquo; program. Partners will be announced at the First Annual
RISC-V Summit in December. Deadline is the end of October.</li>
<li>RISC-V is completing the innovation cycle of research, education, and
industry.</li>
</ul>

<h2 id="hifive-unleashed-expansion-kit-ted-marena:2362d622cd60bdb9d5eb8a1222aae504">HiFive unleashed expansion kit: Ted Marena</h2>

<ul>
<li>Marketing update: Looking for collaboration on a porting to RISC-V
whitepaper. Would also like to see member companies communicating why they
chose RISC-V.</li>
<li>Microsemi set up the MI-V ecosystem to support various RTOSes on soft RISC-V
cores on FPGA.</li>
<li>The Mi-V HiFive Unleashed Expansion board connects to the HiFive board via
FMC. Has PCIe connectors, SATA, HDMI, USB, microSD.</li>
<li>Porting an application from ARM to RISC-V is the same effort as porting from
one ARM SoC to another. No two ARM SoCs have the same memory map or peripheral
functionality. Neither will RISC-V SoCs.</li>
<li>Mi-V HiFive Unleashed board aims to accelerate the RISC-V Linux ecosystem,
enabling the community to port tools, OSes, middleware, packages to RISC-V.</li>
</ul>

<h2 id="simulating-heterogeneous-multi-node-32-bit-and-64-bit-risc-v-systems-running-linux-and-zephry-with-renode-michael-gielda:2362d622cd60bdb9d5eb8a1222aae504">Simulating heterogeneous multi-node 32-bit and 64-bit RISC-V systems running Linux and Zephry with Renode: Michael Gielda</h2>

<ul>
<li>Antmicro: &lsquo;turn ideas into software-driven products&rsquo;</li>
<li>Check out renode.io</li>
<li>Renode is an open source instruction set simulator with a multi-layered
framework on top. It mimics entire platforms.</li>
<li>Cores are implemented in C, and the rest is implemented in C&rsquo;, Python, or
any .NET-compatible language.</li>
<li>Strengths include transparent and robust debugging, easy integration, rich
model abstractions, &hellip;</li>
<li>Renode has a simple platform description format that is human readable,
modular, and extendible.</li>
<li>Also have the capability to simulate entire networks or wireless and wired
devices in one time domain.</li>
<li>Can save and restore whole simulation state.</li>
</ul>

<h2 id="debian-gnu-linux-port-for-risc-v-64-bit-manuel-fernandez-montecelo:2362d622cd60bdb9d5eb8a1222aae504">Debian GNU/Linux port for RISC-V 64-bit: Manuel Fernandez Montecelo</h2>

<ul>
<li>Goal is to have Debian ready to install and run on RISC-V systems.</li>
<li>Debian has more than 27k source packages, and also supports other kernels
such as FreeBSD or GNU Hurd.</li>
<li>There are three kinds of Debian port

<ul>
<li>Those outside of Debian infrastructure, e.g. Raspbian.</li>
<li>Unofficial/unsupported. Not in &lsquo;stable&rsquo; releases but hosted in Debian
infrastructure.</li>
<li>Officially supported. Part of the &lsquo;stable&rsquo; releases and fully supported.</li>
</ul></li>
<li>RISC-V is currently unofficial, working its way towards officially
supported.</li>
<li>Initial plan

<ul>
<li>Bootstrap and create viable, basic OS disk images</li>
<li>Get it to the state of &lsquo;unofficial/unsupported&rsquo;</li>
<li>Move towards an official backend</li>
</ul></li>
<li>Why not 32-bit or 128-bit variants?

<ul>
<li>Too early for 128</li>
<li>32-bit ports struggle to get large packages built. Plus less work has been
done on 32-bit Linux-capable systems.</li>
</ul></li>
<li>Started in 2016, but went in haitus until late 2017/early 2018 for Linux and
glibc upstreaming and freezing of the ABI.</li>
<li>25th Feb - 5th March: Cross-built base set of packages</li>
<li>5th - 13th March: First &lsquo;native&rsquo; build.</li>
<li>13th - 23rd March: Second &lsquo;native&rsquo; build in a clean environment (isolated
environment similar to &lsquo;production&rsquo; auto-builders.</li>
<li>75% of packages are now there. Progress is slowing down as many of the
remaining packages are either very large or difficult.</li>
<li>Uncovered a range of bugs in QEMU, toolchain and so on.</li>
<li>Manuel has a long lost of contributors to thank. Thank you to everyone who
helped make this port happen!</li>
</ul>

<h2 id="fedora-on-risc-v-richard-jones:2362d622cd60bdb9d5eb8a1222aae504">Fedora on RISC-V: Richard Jones</h2>

<ul>
<li>Every few years Red Hat Enterprise Linux is forked from Fedora.</li>
<li>Red Hat and Fedora have a strong upstream first policy</li>
<li>Final bootstrap took 2 months. 16725 builds producing 12785 binary packages</li>
<li>The current build farm contains 2 HiFive unleashed boards, 11 qemu instances
on 4 Intel servers.</li>
<li>The server market is worth about $80B/year annually. 3 billion physical
servers are shipped a year. Of those, x86 servers are about 85% of the market
by value.</li>
<li>Don&rsquo;t make these mistakes for the server market:

<ul>
<li>Require manual intervention to choose the right bootloader/kernel per
vendor</li>
<li>Require out of tree drivers or patches</li>
<li>No standards or constantly changing standards</li>
<li>No organisation providing direction on server standards</li>
<li>Incompatible variants of the ISA meaning a single kernel image can&rsquo;t be
made</li>
<li>Breaking ABIs</li>
<li>Intimately tied to Linux so other OS vendors are excluded</li>
<li>Dev boards being too expensive for developers</li>
</ul></li>
</ul>

<h2 id="smallest-risc-v-device-for-next-generation-edge-computing-seiji-munetoh:2362d622cd60bdb9d5eb8a1222aae504">Smallest RISC-V device for next-generation edge computing: Seiji Munetoh</h2>

<ul>
<li>First target application is authentication. HMAC-SHA256 and variants</li>
<li>Use optical communication for host/device comms</li>
<li>Use SRAM to emulate storage memory chip</li>
<li>The BootROM is synthesized and embedded in the SoC</li>
<li>The first generation processor utilises a PULPino core. Target GF14LP, 300um
x 250uM. 2KB data SRAM. Plus authentication engine, analog custom circuits
(LDO, clock/reset, PD/LED IF).</li>
<li>Created a 2.5D integrated device, use a silicon interposer less than 1mm2.
Processor SoC plus 32KB MPI-SRAM, plus optical IO (MicroLED, MicroPD), plus
power.</li>
<li>Evaluated the architecture using low cost FPGA boards (ZedBoard, Zybo,
Arty).</li>
<li>Moved the instruction SRAM out of the processor die, and evaluate the
performance effect of different widths between processor and external SRAM.
Ended up using an 8-bit bus configuration.</li>
<li>Improved SHA256 performance by adding a hwardware engine.</li>
<li>Made a debug chip packaged in QFP64 wire-bond</li>
<li>Currently testing the 2.5D integrated device</li>
<li>The second generation device was taped out in Feb 2018, featuring a new SoC
design with instruction cache, RF interface, sensors.</li>
</ul>

<h2 id="poster-and-demo-previews:2362d622cd60bdb9d5eb8a1222aae504">Poster and demo previews</h2>

<ul>
<li>Far too fast-paced to summarise. Be sure to come back tomorrow for a new
liveblog. If you&rsquo;re here at the workshop, be sure to come and say hello during
the poster session.</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>lowRISC 0-5 milestone release</title><link>https://www.lowrisc.org/blog/2018/01/lowrisc-0-5-milestone-release/</link><guid>https://www.lowrisc.org/blog/2018/01/lowrisc-0-5-milestone-release/</guid><pubDate>Fri, 12 Jan 2018 14:45:57 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>The <a href="https://www.lowrisc.org/docs/ethernet-v0.5/">lowRISC 0.5 milestone release</a>
is now available. The various changes are best described in our <a href="https://www.lowrisc.org/docs/ethernet-v0.5/">accompanying
documentation</a>, but the main focus
is the integration of open-source Ethernet IP. The tutorial demonstrates how
to use Ethernet support to boot with an NFS root, as well as with a rootfs on
SD card.</p>

<p>Our main development focus currently is migrating to a newer version of the
upstream Rocket chip design and reintegrating our changes on top of that, but
we felt that the integration of Ethernet support merits a release before that
change.</p>

<p>Please report any issues <a href="https://github.com/lowRISC/lowrisc-chip">on our GitHub
repository</a>, or discuss on our
<a href="http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org">mailing
list</a>.
As always, thank you to everyone who has contributed in any way - whether it&rsquo;s
advice and feedback, bug reports, code, or ideas.</p>
 ]]></description></item><item><title>Seventh RISC-V Workshop: Day Two</title><link>https://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-two/</link><guid>https://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-two/</guid><pubDate>Wed, 29 Nov 2017 15:16:45 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2017/10/7th-risc-v-workshop-agenda/">seventh RISC-V
workshop</a> is concluding
today at Western Digital in Milpitas. I&rsquo;ll be keeping a semi-live blog of
talks and announcements throughout the day.</p>

<h2 id="celerity-an-open-source-511-core-risc-v-tiered-accelerator-fabric-michael-taylor:8a3346748fc660bea142337377a70782">Celerity: An Open Source 511-core RISC-V Tiered Accelerator Fabric: Michael Taylor</h2>

<ul>
<li>Built in only 9 months.</li>
<li>Celerity is an accelerator-centric SoC with a tiered accelertor fabric.</li>
<li>Implemented in TSMC 16nm FFC. 25mm2 die area, 385M transistors</li>
<li>Why 511 RISC-V cores? 5 Linux-capable RV64G Rocket cores, 496-core RV32IM
mesh tiled area &ldquo;manycore&rdquo;, 10-core RV32IM mesh tiled array (low voltage).</li>
<li>Used a flip-chip package.</li>
<li>Of the 5 general purpose cores, 4 connect to the manycore array and 1
interfaces with the Binary Neural Network accelerator. Each core executes
independently within its own address space.</li>
<li>The BaseJump manycore architecture implements the RV32IM with a 5-stage
pipeline (full forwarded, in-order, single issue). It has 4KB+4KB instruction
and data scratchpads.</li>
<li>BaseJump Manycore Mesh Network: stores are routed based on the destination.
Simple XY-dimension routing.</li>
<li>Each Rocket core has its own RoCC interface connecting to one of the routers
in the mesh.</li>
<li>Uses a remote store programming model, which enables efficient
producer-consumer programming models. Offer extended instructions such as load
reserved (load value and set the reservation address),
load-on-broken-reservation (stall if the reserved address wasn&rsquo;t written by
other cores), and a consumer instruction to wait on a given address/valud. No
polling or interrupts are required.</li>
<li>Currently working on CUDA support.</li>
<li>Can fit 42 of the &ldquo;manycore&rdquo; cores per mm2 (vs 5 cores per mm2 for Rocket).</li>
<li>80% of the modules in the manycore are from the BaseJump library.</li>
<li>For the backend, hardened each core and replicated across the die.</li>
<li>Over 2/3rds of each manycore tile is memory.</li>
<li>For the BNN: each core in the manycore tier executes a remote-load-store
program to orchestrate sending weights to the specialization tier via a
hardware FIFO.</li>
<li>All code available at <a href="http://opencelerity.org">opencelerity.org</a>.</li>
<li>Want to build the &ldquo;DNA&rdquo; for open source ASICs. i.e. the basic components
needs for building a full system, spanning RTL, IP cores, hardware emulation,
packaging, PCBs. See <a href="http://bjump.org">bjump.org</a>.</li>
<li>The BaseJump STL contains several hundred modules, all parameterised.</li>
</ul>

<h2 id="the-pulp-cores-a-set-of-open-source-ultra-low-power-risc-v-cores-for-internet-of-things-applications-pasquale-davide-schiavone:8a3346748fc660bea142337377a70782">The PULP Cores. A Set of Open-Source Ultra-Low-Power RISC-V Cores for Internet-of-Things Applications: Pasquale Davide Schiavone</h2>

<ul>
<li>PULP: Parallel Ultra-Low Power.</li>
<li>Designed for energy efficient hardware, e.g. near-sensor computation.</li>
<li>Have a set of 3 32-bit cores currently available, and working on a 64-bit
Linux-capable core.</li>
<li>RISCY core has a 4-stage pipeline. RV32IM[F]C. 40.7-69.3kGE. 3.19
CoreMark/MHz. Also has a number of extensions for packed SIMD, fixed point,
bit manipulation and hardware loops.</li>
<li>Zero-riscy has a 2-stage pipeline. RV32{I,E}[M]C. 11.6-18.9kGE. 2.44
CoreMark/MHz for RV32IMC and 0.91 for RV32EC. Optimized for area.</li>
<li>Arian core for Linux. 6-stage pipeline, RV64IMC, 185kGE, OoE execution and
in-order commit. 2.01 CoreMark/MHz.</li>
<li>Also have a set of software tools for PULP. Virtual platform, timing model.
Have 1MIPS simulation speed with timing accuracy between 20-20% of the target
hardware. Can also profile using kcachegrind.</li>
<li>How to verify these cores? Use constrained pseudo-random test generation in
a perturbated environment (random interrupts, stalls). The program generator
tries to maximise the code coverage, and the instruction simulation and RTL
model are compared.</li>
<li>Large number of companies using PULP/PULPino, e.g. Mentor, GreenWaves, NXP,
Micron, Microsemi, Cadence, ST, Google, Intel.</li>
<li>PULPissimo platform will be released Q12018, including the new microDMA
subsystem, new interrupt controller, new SDK etc. Taping out on GF22 soon.</li>
</ul>

<h2 id="boom-v2-an-open-source-out-of-order-risc-v-core-chris-celio:8a3346748fc660bea142337377a70782">BOOM v2. An open-source out-of-order RISC-V core: Chris Celio</h2>

<ul>
<li>Out of order superscalar implementing RV64g. Open source and written in
Chisel (~16kloc). Built on top of the rocket-chip ecosystem.</li>
<li>Advanced branch prediction. Loads can issue out-of-order with regard to
other loads and stores.</li>
<li>Parameterised, just a few lines to instantiate a 2-wide vs 4-wide BOOM.</li>
<li>BOOM has now been taped out! Taped out with a 2 person team in 4 months.</li>
<li>Total LoC for the SiFive U54 Rocket is 34kloc, vs 50kloc for BOOMv2, vs
1.3mloc (Verilog) for the UltraSPARC T2.</li>
<li>Boomv2 achieves 3.92 CoreMark/MHz (on the taped out BOOM), vs 3.71 for the
Cortex-A9.</li>
<li>BOOMv1 had a short pipeline inspired by R10K, 21264, Cortex-A9 and a unified
issue window.</li>
<li>BOOMv2: broke critical paths in the frontend. Put the BTB into SRAM. Also
moved hashing to its own stage.</li>
<li>The first place+route for register file resulted in huge area. Ended up
splitting the unified issue window, splitting the physical register file,
moving issue and register read into separate stages. Then implemented 2-stage
rename and 3-stage fetch.</li>
<li>Didn&rsquo;t have the resources to support a customised register file. A
synthesised register file resulted in huge congestion when routing the wires
from the flip-flops. Instead, black-boxed the register file and hand-wrote
some Verilog to instantiate specific flip-flops, muxes, and tri-state buffers.
Effectively hand-crafting their own bit block out of standard cells.</li>
<li>Saw about a 25% decrease in clock period, and 20% decrease in CoreMark/MHz
(due to increased load-use delay, fixable in the future). A lot of the work
was about fixing design rule check and geometry errors.</li>
<li>Physical design is a bottleneck for agile hardware development. RTL hacking
can be rapid, but it takes 2-3 hours for synthesis results and 8-24 hours for
P+R results. Additionally, manual intervention is often required and reports
are difficult to reason about.</li>
<li>Future directions for BOOM: further IPC and QoR improvements. Chris is
joining Esperanto Technologies, but is committed to maintain the BOOM
open-source repository.</li>
</ul>

<h2 id="rocket-engines-easy-custom-risc-v-cores-through-reuse-albert-magyar:8a3346748fc660bea142337377a70782">Rocket Engines. Easy, custom RISC-V cores through reuse: Albert Magyar</h2>

<ul>
<li>Why are there so many RISC-V cores (or: why not reuse rocket?). Often a
desire to match interface to be a &ldquo;drop in&rdquo; replacement for an existing core,
or want to tailor microarchitecture for custom extensions. Also, may find
Rocket is over-featured for the desired design point.</li>
<li>Less good reasons: not invented here, fear of Chisel.</li>
<li>There are a number of pitfalls for customized cores. e.g. introducing bugs
that have long since been avoided in Rocket.</li>
<li>Avoid reusing either too little or too much. Can reuse individual components
without using the top-level rocket-chip framework at all. Stitch together
individual components.</li>
<li>The &ldquo;big 3&rdquo; components: CSR file, decoder, RISC-V compressed (RVC) expander.</li>
<li>produced a new RISC-V core IP: &ldquo;BottleRocket&rdquo;. This has a classic
three-stage pipeline with a similar microarchitecture to Z-Scale and V-Scale.
Implements RV32IMC. The generator produces a single, easy to connect tile.</li>
<li>Supports debug, test, platform features: 0.13 debug spec, RVFI trace port,
external interrupt controller.</li>
<li>The open sourcing effort is underway, as is the integration with
riscv-formal.</li>
</ul>

<h2 id="a-perspective-on-the-role-of-open-source-ip-in-government-electronic-systems-linton-salmon:8a3346748fc660bea142337377a70782">A Perspective on the Role of Open-Source IP in Government Electronic Systems: Linton Salmon</h2>

<ul>
<li>The USD Department of Defence (DoD) needs custom SoCs. Custom ICs are
necessary to reach the target GOps/W. Computation requirements keep growing,
and real-time results are often required.</li>
<li>Current DoD architectures often use older technology nodes. Now moving
towards newer technology nodes (28nm and below).</li>
<li>Most of the cost for DoD custom SoCs is in design. Typically low volume (1k
parts). For small volume, find design costs 92%, fab NRE 7%, 1% production
costs.</li>
<li>Design cost are skyrocketing, increasingly dramatically with each technology
node. This is a huge problem for the low volume DoD designs.</li>
<li>Is open source IP the answer? The good news is that it can sharply reduce
resources, time and complexity or a DoD custom SoC design. Open source IP
permits increased use of unique DoD security approaches.</li>
<li>The not so good news: the open source community needs to develop a complete
infrastructure, needs to e more robust than it is today, the community needs a
model to fund infrastructure, and the support model must assure long term
support and continued development of open source IP.</li>
<li>Unique differentiation doesn&rsquo;t require development of the entire platform.
Want to put all the effort into the differentiating &ldquo;secret sauce&rdquo;.</li>
<li>Open source IP can address both the cost and availability of standard IP.
Open source IP macros are a critical first step, but integration IP is also
needed.</li>
<li>Open source IP enables specialisation. It provides the blocks and standard
infrastructure that can then be specialised.</li>
<li>Open source IP enables greater scrutiny by the DoD to ensure trust:
assurance it will only do as specified.</li>
<li>Hardware security requires the ability to modify the SoC, including 3d party
IP. Added security capabilities require a robust base and infrastructure.</li>
<li>RISC-V is an adaptable open standard. RISC-V processors can be built in a
way that can be trusted, and RISC-V can be used to enable increased security
(easy to add security extensions).</li>
<li>Need a full ecosystem infrastructure. Need to cover the entire
infrastructure, be robust, and easy to use.</li>
<li>DoD requires robustness and dependability of the open-source infrastructure.
Need complete verification, clear documentation, robustness validated through
to silicon implementation and test. This is not the role or the strength of
universities.

<ul>
<li>Savings requires the ability to depend on the open source IP.</li>
<li>Savings require the robustness of the IP across extended performance
ranges.</li>
</ul></li>
<li>Need a model to fund long-term infrastructure. This isn&rsquo;t the role of DARPA,
which funds projects rather than infrastructure. Much of the work is
difficult, but not exciting.</li>
<li>Need continual maintenance and improvement. Regular updates in terms of
performance, architecture, and fabrication technology.</li>
<li>DARPA programs driving open source IP: PERFECT, CRAFT, SSITH, POSH, IDEA.</li>
<li>CRAFT&rsquo;s goal is to enable more efficient custom IC design/fabrication to
enable high performance electronic solutions faster and with more flexibility.</li>
<li>SSITH: develop hardware design tools and IP to provide inherent security
against hardware vulnerabilities that are exploited through software in DoD
and commercial electronic systems.</li>
<li>IDEA: no &ldquo;human in the lop&rdquo; 24-hour layout generation for mixed signal ICs,
systems in package, and PCBs. Machine generated layout of electrical circuits
and systems.</li>
<li>POSH: an open source System on Chip design and IP ecosystem.</li>
</ul>

<h2 id="boosting-risc-v-isa-with-open-source-peripherals-an-soc-for-low-power-sensors-elkim-roa:8a3346748fc660bea142337377a70782">Boosting RISC-V ISA with Open Source Peripherals. An SoC for Low Power Sensors: Elkim Roa</h2>

<ul>
<li>Challenges: ready-to-plug IP and expensive licenses.</li>
<li>Been working with SiFive, providing IP blocks for the always-on domain.</li>
<li>The power management unit is a state machine running a microcode program
that triggers events as necessary.</li>
<li>Have implemented a wide range of IP: low-noise bandgap voltage reference,
LDO, biasing control, crystal low-frequency driver (XTAL-RF), RC Oscillator,
brownout detector, power-on reset, multi-resolution DAC and ADC, fully
synthesized true random number generator</li>
<li>Finally, integrated these always-on domain blocks in a TSMC180nm SoC using
Chisel at the top level.</li>
<li>Deliverables: releasing Verilog models, FSM Verilog RTL, documentation etc
through the freechips project. Schematics and layout available through the
SiFive Designshare program.</li>
<li>Taping out at the end of the year with SiFive, also want to include PHYs
like SATA, PCIe, USB next year. Hope to have a qualified range of IP in 2019.</li>
</ul>

<h2 id="picosoc-how-we-created-a-risc-v-based-asic-processor-using-a-full-open-source-foundry-targeted-rtl-to-gds-flow-and-how-you-can-too-tim-edwards:8a3346748fc660bea142337377a70782">PicoSoC: How we created a RISC-V based ASIC processor using a full open source foundry-targeted RTL-to-GDS flow, and how you can, too!: Tim Edwards</h2>

<ul>
<li>Created an ASIC version of a RISC-V core (PicoRV32) using an entirely open
source toolflow.</li>
<li>Targeting a 180nm process.</li>
<li>Open source synthesis toolchain: qflow is built using yosys/ABC, vesta,
graywolf, qrouter, magic, netgin, iverilog, ngspice.</li>
<li>PicoSoC includes a UART, SPI memory controller, scratchpad SRAM, and SPI
flash. Started the SoC targeting the open source Lattice ice40 flow, and add
padframe, power-on-reset, and generated SRAM to target ASIC.</li>
<li>Can perform cosimulation using iverilog and ngspice.</li>
<li>The PicoSoC core is 1mm2, with analog+SRAM+padframe, 2mm x 1.5mm.</li>
<li>Can reproduce this yourself using the efabless IP catalog and the efablass
CloudV-based design environment.</li>
<li>This is brought together in the efabless Open Galaxy Design Environment.</li>
</ul>

<h2 id="tilelink-a-free-and-open-source-high-performance-scalable-cache-coherent-fabric-designed-for-risc-v-wesley-terpstra:8a3346748fc660bea142337377a70782">TileLink. A free and open-source, high-performance scalable cache-coherent fabric designed for RISC-V: Wesley Terpstra</h2>

<ul>
<li>Requirements for a RISC-V bus: Open standard, easy to implemented,
cache-coherent block motion, multiple cache layers, reusable on and off-chip,
and high performance.</li>
<li>What about AMBA CHI/ACE?

<ul>
<li>&ldquo;Open standard? CHI is not open!&rdquo;. Can&rsquo;t get hold of the spec.</li>
<li>Not easy to implement: 10 probe message types, split control/data, narrow
bursts, &hellip;</li>
<li>No support for multiple cache layers.</li>
<li>Don&rsquo;t want to depend on a standard controlled by a RISC-V competitor</li>
</ul></li>
<li>TileLink was a clean slate project out of UC Berkeley. Featured a reduced
message protocol, assumed all connected hardware is trusted (do security
checking at the source, not in the network), and only supports power-of-2
block transfers.</li>
<li>TileLink is a master-slave point-to-point protocol. It&rsquo;s message based with
5 priorities. Out-order design with optional ordering. It&rsquo;s designed for
composability and deadlock freedom.</li>
<li>TileLink is open source and in production. Over 30 public modules including
cores, crossbars and adapters. Has a coherency manager similar to how ACE does
snooping. Also have bridges to AXI/AHB/APB</li>
<li>SiFive chips use a banked directory-based wormhole MESI L2$.</li>
<li>There are a few simplifying assumptions that make the protocol easier to
work with.

<ul>
<li>Require there are no agent loops, i.e. the bus participants (agents) form
a directed acyclic graph.</li>
<li>There are strict priorities. Messages have one of five priorities, and
lower priority messages never block higher priority messages. Responses have
a higher priority than requests.</li>
</ul></li>
<li>The on-chip TileLink wire protocol uses an independent channel for each
message priority. Messages are transmitted using multi-beat bursts. Use
ready-valid.</li>
</ul>

<h2 id="the-risc-v-vector-isa-roger-espasa:8a3346748fc660bea142337377a70782">The RISC-V Vector ISA: Roger Espasa</h2>

<ul>
<li>Why a vector extension? Reduce instruction bandwidth, reduce memory
bandwidth, lower energy, exposes DLP, masked execution, gather/scatter.
Scalable from small to large vector processing unit.</li>
<li>The vector ISA in a nutshell

<ul>
<li>32 vector registers. Each can hold either a scalar, vector, or a matrix
(shape). Each has an associated type (polymorphic encoding). There are a
variable number of registers (dynamically changeable).</li>
<li>Vector instruction semantics: all instructions are controlled by the
Vector Length (VL) register and can be executed under mask. Precise
exceptions are supported.</li>
</ul></li>
<li>Suppose you&rsquo;re adding two vector registers: <code>vadd v1, v2 -&gt; v0</code>. If the
vector length is less than maximum vector length, the remaining values must be
zeroed.</li>
<li>You could implement this how you like. Might choose to have a 2-lane
implementation (two FP adders), or 4-lane, or even 8-lane (SIMD, doing all in
one cycle). The number of lanes is transparent to the programmer and the same
code runs independent of the number of lanes.</li>
<li>Data inside a VREG could be a single scalar value, a vector, or a matrix
(optionally). The current shape is held in the per-vreg type field.

<ul>
<li>e.g. <code>vadd v1, v2.s -&gt; v0</code>. This adds the scalar value in v2 to every
value in vector v1.</li>
</ul></li>
<li>Masks are stored in regular vector registers (i.e. there will not be
separate mask registers). Masks are computed with compare operations, and
instructions use 2 bits of encoding to select masked execution.

<ul>
<li>e.g. <code>vadd v3, v4, v1.t -&gt; v5</code>.</li>
<li>v1 is the only register used as mask source.</li>
</ul></li>
<li>Vector load (unit stride). <code>vld 80(x3) -&gt; v5</code> will Vector Length elements.</li>
<li>Stride vector load. <code>vlds 80(x3, x9) -&gt; v5</code> performs a strided load.</li>
<li>Gather (indexed vector load). <code>vldx 80(x3, v2) -&gt; v5</code>. This uses a vector to
hold offsets. Repeated addresses are legal.</li>
<li>Vector store: <code>vst v5 -&gt; 80(x3)</code>. Note that zeroes won&rsquo;t be written when MVL
is larger than the vector length.</li>
<li>Scatter (indexed vector store). <code>vstx v5 -&gt; 80(x3, v2)</code>. Will probably have
two version of scatter, where one has guarantees about the ordering or stores
to repeated addresses.</li>
<li>Ordering:

<ul>
<li>From the point of view of a given hart, vector loads and stores happen in
order. You don&rsquo;t need any fences to see your own stores.</li>
<li>From the point of view of other harts, see the vector memory accesses as
if done by a scalar loop. This means they can be seen out-of-order by other
harts.</li>
</ul></li>
<li>Typed vector registers:

<ul>
<li>Each vector register has an associated type, which can be different for
different registers.</li>
<li>Types can be mixed in an instruction under certain rules.</li>
<li>Register types enable a &ldquo;polymorphic&rdquo; encoding an is also more scalable
for the future.</li>
</ul></li>
<li>vcvt is used for type and data conversions.</li>
<li>In some cases, types can be mixed in an instruction. e.g. adding <code>v1_i8, 
v2_i64 -&gt; v0_i64</code>. When any source is smaller than the destination, the source
is promoted to the destination size.</li>
<li>The size of the vector register file is not set by the ISA. It is configured
by writing to the vdcfg CSR. When doing this, the hardware computes the
maximum vector length. This configuration can be done in user mode.

<ul>
<li>One implementation choice is to always return the same MVL, regardless of
config. Alternatively, split storage across logical registers, perhaps
losing some space.</li>
</ul></li>
<li>E.g the hardware has 32 registers, 4 elements per vector, each 4 bytes = 512
bytes. If the user asks for 32 F32 registers, <code>MVL = 512B / (32 * 4) = 4</code>. If
the user asked for only 2 F32 registers, <code>MVL = 512B / (4+4) = 64</code>. But it
would be legal for the implementation to return something smaller, e.g. 4 as
in the previous example.</li>
<li>If the user asks for 2 F16 regs and 2 F32 registers, <code>MVL = 512B / (12B + 
4B) = 32</code>.</li>
<li>MVL is transparent to software, meaning code can be portable across
different number of lanes and different values of MVL.</li>
<li>Not covered today: exceptions, kernel save + restore, custom types, or
matrix shapes.</li>
<li>Goal is to be the best vector ISA ever! Expect LLVM and GCC to support it.</li>
<li>Current spec on GitHub is out-of-date.</li>
</ul>

<h2 id="security-task-group-update-and-risc-v-security-extension-richard-newell:8a3346748fc660bea142337377a70782">Security task group update and RISC-V security extension: Richard Newell</h2>

<ul>
<li>The security working group works in two main areas. Trusted execution /
isolation and cryptographic extensions. Recently had changes in direction for
trusted execution / isolation.</li>
<li>This talk will focus on the cryptographic extensions status. Hope to have a
written spec for the next workshop.</li>
<li>Want to rely heavily on the vector extensions for crypto.</li>
<li>Use vector functional units to perform modular and Galois Field arithmetic
needed for existing popular and promising post-quantum asymmetric cryptography
schemes. Also accelerate symmetric block ciphers and digest algorithms taking
advantage of the wide vector registers, using specialized VFUs (e.g. AES,
SHA-2).</li>
<li>Asymmetric crypto acceleration: use hardware support for modular arithmetic,
but software for group operations and point multiplication.</li>
<li>Propose vector element widths up to 4096, as well as an escape mechanism to
allow larger widths or non-power-of-two widths.</li>
<li>Intend to use just one major opcode for the cryptographic extension.</li>
<li>Richard presented a handy slide summarising the algorithms used in crypto
suites / libraries. Be sure to check it out once the slides become available!</li>
<li>Proposing to define profiles that define the required crypto algorithms.
e.g. a profile for &ldquo;internet&rdquo;, &ldquo;finance&rdquo;, and &ldquo;cellular&rdquo;.</li>
</ul>

<h2 id="using-proposed-vector-and-crypto-extensions-for-fast-and-secure-boot-richard-newell:8a3346748fc660bea142337377a70782">Using proposed vector and crypto extensions for fast and secure boot: Richard Newell</h2>

<ul>
<li>Richard is giving a great summary of implementing various crypto algorithms
using the proposed crypto extensions, but unfortunately it&rsquo;s difficult to
summarise the information presented in these diagrams.</li>
<li>Expect a huge speedup vs the ARM Cortex-M3 for an appropriate RV32IVY
implementation (though very dependent on the hardware that is implemented).</li>
<li>Performed a case study using WalnutDSA signature verification, developed by
SecureRF. Saw a 3x speedup with crypto extensions vs without crypto
extensions.</li>
</ul>

<h2 id="using-risc-v-as-a-security-processor-for-darpa-chips-and-commercial-iot-mark-beal:8a3346748fc660bea142337377a70782">Using RISC-V as a security processor for DARPA CHIPS and Commercial IoT: Mark Beal</h2>

<ul>
<li>This talk is about leveraging RISC-V to deliver integrated hw/sw silicon IP.</li>
<li>The Intrinsix secure execution environment contains a tiny RISC-V core,
crypto engines, secure fabric, as well as software.</li>
<li>Add a security CPU to provide an isolated execution environment. It&rsquo;s easier
to verify the separation between secure and non-secure actions. Costs less
than 1% of silicon area (20K gates).</li>
<li>Implement RV32IC with machine and user modes. 2-stage pipeline with a local
ROM And RAM. The IRAM can only hold signed code, is fetch-only, and is locked
after authentication.</li>
<li>Security RV32 runs signed firmware in user mode, and only executes from
hardwired ROM in machine mode.</li>
<li>Suppose you have Zephyr running on Rocket, using TinyCrypt as the crypto
API. Replace TinyCrypt on Rocket with a call to an API running on the Secure
RV32.</li>
</ul>

<h2 id="isa-formal-task-group-update-rishiyur-nikhil:8a3346748fc660bea142337377a70782">ISA Formal Task Group Update: Rishiyur Nikhil</h2>

<ul>
<li>A formal spec is a key requirement to be able to definitively answer
questions about compiler correctness and implementation correctness. e.g. will
executing this RISC-V program on this implementation produce correct results?<br />
For all RISC-V programs?</li>
<li>Clifford Wolf has demonstrated the value of formal spaces in identifying
bugs in most publicly available RISC-V implementations.</li>
<li>The formal spec must be clear and understandable to the human reader,
precise and complete, machine readable, executable, and usable with a variety
of formal tools.

<ul>
<li>English-text specs and instruction set simulators can be regarded as
specs, but typically do not meet many of these goals.</li>
</ul></li>
<li>Our approach is to use a very minimal subset of Haskell to define a spec
that is directly executable in Haskell. Then provide parsers to connect to
other formal tools and formats.</li>
<li>See the current prototype
<a href="https://github.com/mit-plv/riscv-semantics">here</a>.</li>
<li>Done: RV32I/RV64I, M, priv spec M. Currently ignoring memory model issues.
Soon want to implement privilege spec supervisor mode, then A, C, F, D,
integration with the memory model.</li>
</ul>

<h2 id="strong-formal-verification-for-risc-v-adam-chlipala:8a3346748fc660bea142337377a70782">Strong formal verification for RISC-V: Adam Chlipala</h2>

<ul>
<li>Simplify: start by proving a shallow property, proving some straight-forward
invariants.</li>
<li>Simplify: analyze isolated components and build larger components by
composing them.</li>
<li>Want to avoid starting over for each design. Instead prove a property once
for all parameters.</li>
<li>Kami is a framework to support implementing, specifying, formally verifying,
and compiling hardware designs. It is based on the Bluespec high-level
hardware design language and the Coq proof assistant.</li>
<li>The big ideas (from Bluespec):

<ul>
<li>Program modules are objects with mutable private state accessed via
methods.</li>
<li>Every method call appears to execute atomically. So any step is summarized
by a trace of calls.</li>
</ul></li>
<li>Object refinement is inclusion of all possible traces.</li>
<li>Composing objects hides internal method calls.</li>
<li>Use standard Coq ASCII syntax for mathematical proofs. These are checked
automatically, just like type checking. Also benefit from streamlined IDE
support for Coq.</li>
<li>Implement a design, which can be refined to check it against the spec (Coq
tactics are used to prove the refinements). The design is also used to
generate the RTL.</li>
<li>We are building a translator for the formal RISC-V ISA spec into the
language of Coq/Kami.</li>
<li>Building an open library of formally verified components. Built a
microcontroller-class RV32I. Working on desktop-class RV64IMA. Also have a
cache-coherent memory system.</li>
<li>Reuse our proofs when composing our components with your own formally
verified accelerators.</li>
</ul>

<h2 id="grvi-phalanz-update-jan-gray:8a3346748fc660bea142337377a70782">GRVI Phalanz Update: Jan Gray</h2>

<ul>
<li>The industry is looking to FPGAs to help accelerate cloud workloads.</li>
<li>Software challenge is how to map you multithreaded C++ app to your
accelerator. On the hardware side, you want to avoid endless tapeouts as you
tweak your algorithm.</li>
<li>GRVI Phalanx Accelerator Kit is a parallel processor overlay for
software-first accelerators. Recompile your application and run on hundreds of
RISC-V cores.</li>
<li>GRVI: FPGA-efficient RISC-V processing element. No CSRs or exceptions, but
does implement mul and lr/sc.

<ul>
<li>3-stage pipeline with some resources shared by a pair of cores. Fits in
320 LUTs.</li>
<li>Take 8 of these and connect to form a cluster (8PEs, shared RAM). Takes
approximately 3500 LUTs.</li>
</ul></li>
<li>Compose cores using message passing on the FPGA-optimised Hoplite NoC.</li>
<li>Use a partitioned global address space (PGAS).</li>
<li>Phalanx: fabric of clusters of PEs, memories, IOs</li>
<li>FPGAs used in the AWS F1 are huge, over 1.3M LUTs. Last December, fit 1680
RISC-V cores on that FPGA. 250MHz, 420GIPS, 2.5TB/s cluster memory bandwidth,
&hellip;</li>
<li>Working on a GRVI Phalanx SDK. Bridge the Phalanx and AX4 system interfaces
with message passing bridges.</li>
<li>8-80 cores on the Pynq.</li>
<li>Can fit 884 cores on the FPGA on the F1 with 3 DDR controllers, 1240 with 1
DDR controller.</li>
<li>Currently program using bare metal multithreaded C++ and message. Working on
an OpenCL-based solution. Use the new &lsquo;SDAccell for RTL&rsquo;.</li>
<li>SDK coming, allowing 8-80-800-10000 core designs. All enabled by the
excellent RISC-V ecosystem.</li>
</ul>

<h2 id="a-tightly-coupled-light-weight-neural-network-processing-unit-with-risc-v-core-lei-zhang:8a3346748fc660bea142337377a70782">A tightly-coupled light-weight neural network processing unit with RISC-V Core: Lei Zhang</h2>

<ul>
<li>Neural networks can be used to replace computation-intensive but
error-resilient code.</li>
<li>Connected a tightly-coupled neural accelerator to a Rocket core through the
RoCC interface.</li>
<li>Extended the instruction set. Added NPE instructions for neural accelerator
initialisation and invocation. Also DMA instructions for data initialization
in a buffer. Finally, AGU instructions for data streaming from buffer to
processing elements.</li>
<li>The Neural Accelerator is a one-dimensional systolic array.</li>
</ul>

<h2 id="lacore-a-risc-v-based-linear-algebra-accelerator-for-soc-designs-samuel-steffi:8a3346748fc660bea142337377a70782">Lacore: A RISC-V based linear algebra accelerator for SoC designs: Samuel Steffi</h2>

<ul>
<li>Linear algebra is a foundation of high performance computing.</li>
<li>Most HPC apps can be reduced to a handful of computation classes:
sparse/dense linear algebra, FFT, structured/unstructured grids. These all
have overlap with linear algebra.</li>
<li>LACore targets a wide range of applications and tries to overcome hardware
issues of other approaches (GPU, fixed-function accelerators).</li>
<li>Five main pieces in the LACore additions to the scalar SCPU

<ul>
<li>LAExecUnit: mixed-precision systolic datapath connected to LAMemUnits with
FIFOs. 3 inputs and 1 output, dual precision (32 and 64-bit). Datapath
consists of a vector unit and a reduction unit.</li>
<li>LAMemUnits: read and write data-streams to the datapath FIFOs and
LACache/Scratchpad. Can read or write scalars, vectors, matrices, and sparse
matrices.</li>
<li>LAcfg provides configuration to LAMemUnits. These registers hold all info
about data-stream type, precision, location etc.</li>
<li>64kb scratchpad (3r1w).</li>
<li>64kb LACache with 4 ports (3r1w) and 16 banks</li>
</ul></li>
<li>Adding 68 new instructions, broadly split into 3 classes: configuration,
data movement, and execution.</li>
<li>The LACoreAPI allows the accelerator to be programmed.</li>
<li>Started by implementing in gem5. This was ~25kloc of C++ and Python.</li>
<li>Implemented the HPC Challenge (HPCC) benchmark suite. Compared versus a
in-order RISC-V core, superscalar x86 core with SSE2, and equivalent Fermi GPU
with 2 streaming multiprocessors. LACore saw a speedup of 3.43x over x86,
10.72x vs baseline RISC-V, and 12.04 vs the GPU baseline.</li>
<li>Estimated area is only 2.53x the area of a single RISC-V scalar CPU and
0.60x the area of the equivalent GPU.</li>
<li>Freely available <a href="https://github.com/scale-lab/la-core">here</a>.</li>
<li>Currently working a LACore multi-core design and evaluation, as well as an
ASIC implementation and eventual tapeout.</li>
</ul>

<h2 id="packet-manipulation-processor-a-risc-v-vliw-core-for-networking-applications-salvatore-pontarelli:8a3346748fc660bea142337377a70782">Packet manipulation processor. A RISC-v VLIW core for networking applications: Salvatore Pontarelli</h2>

<ul>
<li>Network &ldquo;softwareization&rdquo; is seen as the optimal solution to design next
generation network infrastructures, services, and applications.</li>
<li>Want high speed: 100-200Gbps (as achievable with FPGAs and network
processors) and beyond, 5Tbps as achievable with programmable forwarding
dataplanes.</li>
<li>Propose an architecture where programmable forwarding dataplanes are
augmented with a PMP (packet manipulation processor)</li>
<li>Design a small, efficient CPU for packet manipulation. Deploy the PMP at the
output port. Want to process packets at 10/40Gbps.</li>
<li>Possible programmable actions: inband packet reply, custom tunneling,
NAT/PNAT.</li>
<li>The PMP has a small instruction memory (typically need less than 8K
instructions). Small data memory (8KB). Flat memory, no cache hierarchy.</li>
<li>PMP throughput: 10Gbps is 14.88Mpps, 67 clock cycles at 1GHz. A multi-core
CPU is one approach, but has challenges regarding the reordering of packets.
Pursue a VLIW solution instead.</li>
<li>The PMP is a static 8-issue VLIW RISC-V core with the RV32I instruction set.
Has a 32-bit dataplane (to be upgraded). Written in VHDL. Features branch
prediction, lane forwarding.</li>
<li>Implemented in a NetFPGA based programmable dataplane.</li>
<li>Synthesized at 250MHz on FPGA.</li>
</ul>

<h2 id="adding-a-binarized-cnn-accelerator-to-risc-v-for-person-detection-guy-lemieux:8a3346748fc660bea142337377a70782">Adding a Binarized CNN Accelerator to RISC-V for Person Detection: Guy Lemieux</h2>

<ul>
<li>This talk uses VectorBlox Vector instructions, which are not the same as the
vector instructions proposed in the RISC-V vector working group.</li>
<li>Prototyped in the Lattice iCE40 UltraPlus FPGA (5280 LUTs, 1Mb SRAM).</li>
<li>Inspired by BinaryConnect. Built a custom database, performed other
optimisations, and managed 98% accuracy.</li>
<li>Use Orca (open source, BSD licensed). Written in VHDL, 200MHz fully
pipelined, less than 2000 4LUTs.</li>
<li>Added streaming vector extensions and binary CNN accelerator.</li>
<li>The streaming vector instructions (SVE) operate only on stream memory. Add
streaming version of all the base RV32 integer operations, multiply
instructions. Add in some extra instructions such as mov, conditional move,
comparisons, and vector control instructions. Packed SIMD can be supported
naturally with this approach to vectors.</li>
<li>Would also like to add an extra SVE extension for DMA.</li>
<li>SVE has a base 32-bit encoding, as well an extended 64-bit encoding.</li>
<li>Can redirect the data to a domain-specific streaming pipeline.</li>
<li>4852 4-input LUTs for the whole solution.</li>
<li>Releasing the VectorBlox instruction set as an open specification, and
joining the RISC-V vector working group to discuss it as a potential
alternative.</li>
<li>SVE vs the RISC-V vector extension

<ul>
<li>A &ldquo;memory-to-memory&rdquo; architecture, challenging the conventional wisdom of
RISC.</li>
<li>No named vector registers in the ISA (no register allocation, no compiler
changes needed)</li>
<li>High performance. Free loop unrolling, no saving/restoring of vector data.</li>
<li>No storage wasted with streaming memory. Free software scratchpad if
vectors aren&rsquo;t used.</li>
<li>Easier/simpler hardware. Double-buffered DMA instead of prefetching +
vector register renaming.</li>
</ul></li>
</ul>

<h2 id="risc5-improving-support-for-risc-v-in-gem5-alex-roelke:8a3346748fc660bea142337377a70782">RISC5. Improving support for RISC-V in gem5: Alex Roelke</h2>

<ul>
<li>gem5 is a popular cycle approximate simulator, which can be very useful in
RISC-V hardware development.</li>
<li>RISC-V in gem5 supports RV64GC. It uses syscall emulation and doesn&rsquo;t yet
support the privileged ISA.</li>
<li>Implemented the release consistency memory model for atomics.</li>
<li>Floating point support was verified against spike and a hardware design.</li>
<li>The main challenge when implementing the compressed instruction was
interfacing with gem5&rsquo;s existing decode logic.</li>
<li>In the future, want to support multithreaded workloads in syscall emulation
mode, enable full system mode (privileged ISA), and correct minor differences
(e.g. floating point rounding).</li>
</ul>

<h2 id="renode-a-flexible-open-source-simulation-for-risc-v-system-development-michael-gielda:8a3346748fc660bea142337377a70782">Renode. A flexible open-source simulation for RISC-V system development: Michael Gielda</h2>

<ul>
<li>AntMicro was founded in 2009 and has been developing Renode since 2010.</li>
<li>Why did we build Renode? Observed data workflows for embedded development.
Needed a fast simulator for software developers, as close to production as
possible. Must support multi-node simulation, easy reuse of models, and be
extensible.</li>
<li>It is an instruction set simulator, mostly written in C#. It supports fully
deterministic execution, transparent debugging, integration with familiar
tools (e.g. GDB).</li>
<li>Renode is open source, has a flexible structure and is constructed out of
modular building blocks.</li>
<li>The platform description format is human readable, modular, and extendible.</li>
<li>Worked with Microsemi to support the Mi-V platform, integrate with
SoftConsole IDE, and support Windows as a first-class platform.</li>
<li>Renode supports a range of handy features, such as fault injection,
record/replay, and more.</li>
</ul>

<h2 id="qemu-based-hardware-modelling-of-a-multi-hard-risc-v-soc-daire-mcnamara:8a3346748fc660bea142337377a70782">QEMU-based hardware modelling of a multi-hard RISC-V SoC: Daire McNamara</h2>

<ul>
<li>Wanted to explore have separate execution contexts on the same SoC that are
free from interference (e.g. one core running an RTOS, while others run a
general purpose OS).</li>
<li>In the SiFive Unleashed platform, the E51 provides services for other U54
harts.</li>
<li>E51 services/peripheral drivers are implemented as event-driven state
machines. These are describes via a structure and states are named.</li>
<li>Needed an emulator to model all of this.</li>
<li>Modified RISC-V QEMU:

<ul>
<li>Updated privileged spec support.</li>
<li>Hart synchronisation (IPIs)</li>
<li>Modelling physical memory protection</li>
<li>PLIC, CLINT, local interrupts</li>
<li>Support for managing contexts of multiple harts</li>
<li>Modelling L1/L2 cache configuration register writes/reads</li>
<li>&hellip;</li>
</ul></li>
<li>U54-MC QEMU hasn&rsquo;t yer been upstreamed to the main RISC-V QEMU github repo
yet.</li>
<li>Can boot Linux to console and interact, but it&rsquo;s a little slow (takes about
15 minutes).</li>
<li>Future plans: improve speed, add vectorisation for local interrupts, device
tree support, QOM, remote control of real hardware. Finally, clean up and
upstream.</li>
</ul>

<h2 id="firesim-cycle-accurate-rack-scale-system-simulation-using-fpgas-in-the-public-cloud-sagar-karandikar:8a3346748fc660bea142337377a70782">FireSim. Cycle-Accurate Rack-Scale System Simulation using FPGAs in the Public Cloud: Sagar Karandikar</h2>

<ul>
<li>Why simulate datacenters? Next-gen datacenters won&rsquo;t be built only from
commodity components, and custom hardware is changing faster than ever.</li>
<li>Our simulator needs to model hardware at scale (CPUs down to
microarchitecture, fast networks and switches, novel accelerators), run real
software, and be usable.</li>
<li>One way to test would be to build the hardware, get the chips back, then
network together into a datacenter. This has obvious disadvantages.</li>
<li>Alternatively, use a software simulator. Easy to prototype new hardware this
way, but also easy to model something that you can&rsquo;t build. Additionally, it
can be very slow to run, requiring the use of small microbenchmarks or
sampling.</li>
<li>Or, build a hardware-accelerated simulator (see DIABLO). You need to
hand-write RTL models, which in many ways is harder than &ldquo;tapeout-ready&rdquo; RTL.</li>
<li>How do we improve? Harness useful hardware trends such as the open RISC-V
SoC, open silicon designs, high productivity hardware design languages
(Chisel), FPGAs in the cloud.</li>
<li>FireSim target design: server blades, each with quad-core RISC-V Rocket at
3.2GHz, 16KiB I+D cache, 256KiB L2, 16Gb DRAM, 200Gbps Ethernet NIC, optional
accelerators. The network has parameterisable bandwidth/link latency and a
configurable topology.</li>
<li>Transform the RTL to simulate on the FPGA. For the network simulation, use
CPUs and the host network (one thread per port).</li>
<li>FAME-1 transforming RTL: given RTL, want to automatically transform it into
decoupled cycle-accurate simulator RTL that we can run on the FPGA.</li>
<li>Can pack four quad-core server simulations per FPGA, meaning 32 server
simulations per f1.16xlarge (128 simulated cores). Use a 32-port 200Gbps
per-port top of rack switch model. The simulation runs at 5MHz (~400 million
instructions/second). $13.20/hr on-demand, ~$2.60/hr on the spot market.</li>
<li>Can scale to simulating a 1024 node RISC-V datacenter. Ran across 32
f1.16xlarge instances. In aggregate, runs at 3.4MHz (13 billions insts/s
across the simulated datacenter).</li>
<li>Can also achieve &ldquo;functional&rdquo; network simulation. e.g. allowing all of
SPECInt06-ref to run on Rocket Chip at 150MHz (completing in less than one
day).</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>Seventh RISC-V Workshop: Day One</title><link>https://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-one/</link><guid>https://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-one/</guid><pubDate>Tue, 28 Nov 2017 15:16:45 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2017/10/7th-risc-v-workshop-agenda/">seventh RISC-V
workshop</a> is going
on today and tomorrow at Western Digital in Milpitas. I&rsquo;ll be
keeping a semi-live blog of talks and announcements throughout the day.</p>

<p>Follow <a href="https://www.lowrisc.org/blog/2017/11/seventh-risc-v-workshop-day-two/">here</a> for the
day two live blog.</p>

<h2 id="introduction-rick-o-connor:c75429522933c8c4c55bd90283936952">Introduction: Rick O&rsquo;Connor</h2>

<ul>
<li>Workshop is sold out, 498 attendees registered representing 138 companies
and 35 universities.</li>
<li>There will be 47 sessions squeezed into 12 and 24 minute increments, plus 26
poster / demo sessions.</li>
<li>The 8th RISC-V workshop will be held on May 7th-10th at the Barcelona
Supercomputing Center and Universitat Politecnica de Catalunya.</li>
<li>Rick gives a refresher on the structure of the RISC-V Foundation.</li>
<li>The RISC-V Foundation now has only 100 members (including individual
members).</li>
<li>We&rsquo;re on a <em>tight</em> schedule today. No applause and no questions!</li>
</ul>

<h2 id="risc-v-state-of-the-union-krste-asanovic:c75429522933c8c4c55bd90283936952">RISC-V state of the union: Krste Asanovic</h2>

<ul>
<li>Krste gives a rapid overview of the RISC-V ISA.</li>
<li>RISC-V aims to be simple, clean-slate, modular, and stable.</li>
<li>RISC-V started in May 2010. v1.0 of the ISA came in 2011, first Rocket
tapeout in 2012, first Linux port in 2013, v2.0 (frozen) IMAFD spec in 2014.
First commercial softcores and first commercial SoC in 2017.</li>
<li>Large companies are adopting RISC-V for deeply embedded controllers in their
SoCs (&ldquo;minion cores&rdquo;), replacing home-grown and commercial cores.

<ul>
<li>[Editor&rsquo;s note: pleasing to see the &ldquo;minion core&rdquo; name take off around the
wider RISC-V community!].</li>
</ul></li>
<li>Small and proprietary-ISA soft-core IP companies are switching to the RISC-V
standard to access a larger market. &ldquo;If you&rsquo;re a softcore IP provider, you
should have a RISC-V product in development&rdquo;.</li>
<li>RISC-V has seen government adoption, e.g. India adopted it as a national
ISA. A recent security-focused DARPA project standardised on RISC-V. Israel
Innovation Authority are creating the GenPro platform around RISC-V.</li>
<li>Many startups are choosing RISC-V for new products. &ldquo;We haven&rsquo;t had to tell
startups about RISC-V; they find out about it very quickly when shopping for
processor IP&rdquo;.</li>
<li>Commercial ecosystem providers: starting to see mainstream commercial
support. &ldquo;Demand is driving supply in the commercial ecosystem&rdquo;.</li>
<li>RISC-V in academic research: becoming the standard ISA for academic
research. There will be talks at the workshop about the Celerity 500 RISC-V
core SoC in 16nm FinFET, and FireSim which models 1024 quad-core RISC-V
servers in the cloud.

<ul>
<li>The CARRV RISC-V workshop at MICRO was even better attended than the
machine learning workshop.</li>
</ul></li>
<li>Expect in a few years time that the vast majority of undergraduates will be
taught RISC-V at University.</li>
<li>Racepoint Global have been hired for Foundation marketing.</li>
<li>RISC-V Technical Roadmap for 2017:

<ul>
<li>Primary goal was to formally standardise the base ISA, resolve issues with
the memory model, debug, and stabilize the privileged architecture.</li>
<li>Good progress has been made, but the spec hasn&rsquo;t yet been ratified. One of
the issues is differentiating the base spec versus clarifications for
different &ldquo;profiles&rdquo;. There is no plan to change any instruction
specification versus 2.0.</li>
<li>The Unix platform is stable as of the privileged 1.10 spec (i.e. no
backwards incompatible changes from now on).</li>
</ul></li>
<li>ISA specifications and profiles

<ul>
<li>The original ISA specs mixed instruction specifications with platform
mandates. Now work is ongoing to separate instruction set specifications
from platform profiles.</li>
<li>Instruction set specifications should be maximally reusable, while the
profiles should be as constrained as possible to simplify software
compatibility.</li>
</ul></li>
<li>Single-letter names will run out some day, so a proposal has been made to
allow finer-grained naming of instruction sets to describe profiles. Use Zxxxx
to name standard instruction extensions (while Xyyyyy is used for non-standard
instruction extensions). See the isa-dev list for more information.</li>
<li>Profiles for software compatibility. A software ABI/SBI defines a profile.
A software ABI/SBI defines a profile. Also need profiles M-mode-only
microcontrollers, and MU-mode microcontrollers, and for booting MSU platforms.
Aim for have first ready in Q12018.</li>
<li>Memory model: the original was too weak for C11 and underspecified, but a
team of experts have come together over the past year to resolve the issues.
RVWMO is the base memory model and is weak, while RVTSO is an optional
extension providing a strong TSO memory model.</li>
<li>Calling convention and ABI has been stabilized and documented.</li>
<li>GCC and binutils have been upstreamed and released in GCC. LLVM upstream is
in progress.</li>
<li>A number of other compilers and languages are now available. e.g. CompCert,
Go, Rust, OCaml, Jikes JVM, OpenJDK, &hellip;</li>
<li>The Linux port has been accepted upstream for the 4.15 release.
Additionally, the hypervisor spec has been released (designed to support
recursive virtualisation using an enhanced S mode).</li>
<li>Run-halt debug going well, is being targeted by commercial vendors.</li>
<li>2017 summary: All planned major technical decisions settled, some more work
on the ratification process is needed.</li>
<li>Technical roadmap goals for 2018:

<ul>
<li>Complete ratification of base ISA and first profiles</li>
<li>Base vector extensions proposed and ratified</li>
<li>Hypervisor implemented, spec ratified</li>
<li>Formal spec completed and released</li>
</ul></li>
<li>Vector: see the talk from Roger. Aim to be the Best Vector ISA Ever &trade;.</li>
<li>Security: really two separable efforts in the foundation: trusted execution
environments and cryptographic instruction extensions. Also a huge amount of
other work in the academic community.</li>
<li>Interrupts: currently have fast local interrupts and global platform-level
interrupts. Also have requests for high end systems who want per-hart
message-signal interrupts (MSI) and from low-end embedded that want
pre-emptive vectored prioritized interrupts.</li>
<li>Improving embedded compression: the C extension was designed for general
purpose computing with Unix binaries. People are seeing non-competitive RISC-V
code size on pure embedded workloads, like due to lack of byte/halfword memory
access? Considering an alternative C extension for RV32E systems.</li>
<li>A new task group has been up for the &lsquo;J&rsquo; extension, exploring support for
dynamically translated languages. Looking at issues like integer overflow,
garbage collection, and instruction cache management.</li>
<li>Summary

<ul>
<li>Very rapid development and adoption &ldquo;by the time you decide to do a
project, support will be there&rdquo;.</li>
</ul></li>
<li>Question: does the foundation have any formal ways of addressing IP
challenges? Answer: have been documenting prior art for the base ISA
instructions. Would be good to continue to expand this to cover reference
hardware implementations.</li>
</ul>

<h2 id="risc-v-hypervisor-extension-andrew-waterman:c75429522933c8c4c55bd90283936952">RISC-V Hypervisor Extension: Andrew Waterman</h2>

<ul>
<li>Presenting work with extensive contributions from Paolo Bonzini and John
Hauser</li>
<li>Goal is to virtualize S-mode to support running guest OSes under Type-1,
Type-2 and hybrid hypervisors. Also want to be high performance and to support
recursive virtualisation.</li>
<li>The hypervisor extension adds new privileged modes. S-mode becomes HS-mode,
and we also add the Virtualised Supervisor (VS) and Virtualized User (VU)
modes.</li>
<li>What needs to be virtualized? Supervisor architecture state (CSRs), memory,
I/O and interrupts.</li>
<li>Additional copies of most supervisor CSrs are provisioned as background
supervisor CSRs, e.g. bsscratch, bsepc. In HS-mode, foreground CSRs contain
S-mode state and background CSRs contain inactive VS-mode state. These are
swapped in VS-mode.</li>
<li>Use two-level address translation to virtualize memory. Original virtual
addresses are translated to guest physical addresses by the VS-level page
table, and then guest physical addresses are translated to machine physical
addresses by the HS-level page table.

<ul>
<li>Page table entry formats and page table layouts are the same as S-mode</li>
</ul></li>
<li>Software and timer interrupts are easy to virtualise, as they&rsquo;re already
exposed via the SBI. The two-level paging scheme can be used to trap MMIO
accesses.

<ul>
<li>Could avoid extra traps into the hypervisor with a virtualisation-aware
PLIC. This is considered a platform issues, outside of the scope of the
hypervisor ISA.</li>
</ul></li>
<li>Need an I/O MMU to initiated DMAs without trap into the hypervisor - also a
platform issue.</li>
<li>The hypervisor extension is designed to be efficiently emulatable on M/S/U
systems with traps into M-mode.</li>
<li>Specification v.01 is <a href="https://github.com/riscv/riscv-isa-manual">available on
GitHub</a>. Hoping to implement in
Spike in Q1 2018.</li>
<li>Want to see a silicon implementation prior to ratification.</li>
</ul>

<h2 id="risc-v-memory-consistency-model-status-update-dan-lustig:c75429522933c8c4c55bd90283936952">RISC-V memory consistency model status update: Dan Lustig</h2>

<ul>
<li>The goal was to define the RISC-V memory consistency model (&ldquo;specifies the
values that can be returned by loads&rdquo;). Support a wide range of hardware
implementations, as well as Linux, C/C++ and lots of other critical software.</li>
<li>The fundamental debate was about strong models (such as x86-TSO) vs weak
models (ARM, IBM Power). Strong models have stricter ordering rules, resulting
in something that&rsquo;s simpler for programmers and for architects. Weak models
have more relaxed ordering rules, better performance/power/area and more
microarchitectural freedom.</li>
<li>In order to find a compromise, defined RVTSO (strong) and RVWMO (weak).

<ul>
<li>Both are multi-copy atomic. This means cores are allowed to peek at stores
they have issues as long as they haven&rsquo;t been observed by anyone else and is
much simpler to reason about than the Power and ARMv7 memory models.</li>
</ul></li>
<li>The base RISC-V memory model is RVWMO (software must assume this if it wants
to be portable). It&rsquo;s important to note that a hardware implementation meeting
the RVWMO specification could be more conservative (stronger). Additional have
the Ztso extension for RVTSO, which software might target.</li>
<li>RVWMO and RVTSO differ in the degree of memory access reordering they permit
at the point of global visibility. In RVTSO, only store-to-load reordering can
be observed. In RVWMO, most memory accesses can be reordered freely unless
synchronized via .sq, .rl and/or fences.</li>
<li>Dan has some handy diagrams that explain the RVWMO and RVTSO rules in a
nutshell, which you should be able to study once the slides become available.</li>
<li>Software written for RVWMO will run on all RISC-V hardware (RVWMO and Ztso).
RVTSO-only software can be be written, but will only run on hardware
implementing Ztso. A flag in the ELF header will be used to ensure this.</li>
<li>If you don&rsquo;t want to think about memory models, just use the standard OSes
and toolchains. If you care about PPA or flexibility, use RVWMO. If you have
lots of legacy x86 code, use hardware implementing Ztso so that any software
will work. If you believe TSO is the future, use hardware with Ztso and emit
code with the TSO-only magic number.</li>
<li>Fragmentation due to the presence of two memory models is an obvious risk.
Try to discourage software from targeting both, and encourage targeting RVWMO
wherever possible (redundant fences simple become no-ops).</li>
<li>There have been a number of other ISA changes. ld.rl and sd.aq are
deprecated. ld.aqrl and sd.aqrl mean RCsc. Also clarified other subtleties.
May have future extensions to the fence instruction, and .aq/.rl variants for
byte and halfword-size loads/stores.</li>
</ul>

<h2 id="risc-v-enabling-a-new-era-of-open-data-centric-computing-architectures-martin-fink:c75429522933c8c4c55bd90283936952">RISC-V - Enabling a new era of open data-centric computing architectures: Martin Fink</h2>

<ul>
<li>Most people think of Western Digital as a storage company, but actually
they&rsquo;re a <em>data</em> company.</li>
<li>Big data is well known, but increasingly there are applications that require
&ldquo;fast data&rdquo; (immediate access to information).</li>
<li>Big data applications have historically focused on general purpose compute.
But we need to be able to move beyond general purpose compute to meet new
application requirements.</li>
<li>In a general purpose compute architecture, everything is centered around the
CPU rather than the data.</li>
<li>Workload diversity demands diverse technologies and architectures, both for
&ldquo;big data&rdquo; and &ldquo;fast data&rdquo;.</li>
<li>There are a wide range of data-centric applications at the edge.</li>
<li>RISC-V meets the needs of big data (move compute to data) and fast data
(memory centric compute). It enables purpose-built environments for big data
and fast data applications.</li>
<li>Western Digital ships in excess of 1 billion cores per year, and expect to
double that. They are making a commitment to transition all of those 1 billion
cores towards RISC-V, across their whole product portfolio.</li>
<li>Want to process the data where it lives, which RISC-V will help to enable.</li>
<li>Represents a new style of development. In some cases, WD may develop their
own cores, in others may buy them, in others may partner with another company
to co-develop them.</li>
<li>Western Digital will work to accelerate the RISC-V ecosystem:

<ul>
<li>Support the development of open source IP building blocks for the
community</li>
<li>Actively partner and invest in the ecosystem</li>
<li>Accelerate development of purpose-built processors for a broad range of
Big Data and Fast Data environments</li>
<li>Multi-year transition of Western Digital devices, platforms and systems to
RISC-V purpose built architectures</li>
</ul></li>
<li>First device from WD with a RISC-V core is likely to not ship until late
2019 to early 2020.</li>
<li>Summary

<ul>
<li>Big Data and Fast Data need purpose-built environments</li>
<li>Openness and ecosystem enable best-in-class innovation. The motivation is
enabling innovation, <em>not</em> reducing cost.</li>
<li>Western Digital brings the momentum of over 1B cores per year</li>
</ul></li>
</ul>

<h2 id="industrial-strength-high-performance-risc-v-processors-for-energy-efficient-computing-dave-ditzel:c75429522933c8c4c55bd90283936952">Industrial-strength high-performance RISC-V processors for energy-efficient computing: Dave Ditzel</h2>

<ul>
<li>Coming out of &ldquo;stealth mode&rdquo; in this talk.</li>
<li>Chris Celio is joining Esperanto, but will continue to maintain and support
BOOM. Esperanto will also be implementing even higher performance out-of-order
processors.</li>
<li>Esperanto have been pursuing an implementing of the draft Vector ISA in
order to understand design trade-offs.</li>
<li>RISC-V is off to a great start, but many in industry view RISC-V as a
curiosity or toy, only for low end. Repeatedly see questions about high-end
designs (in Verilog!), graphics, machine learning, or HPC applications.</li>
<li>See Esperanto as complementing existing core vendors, &ldquo;expanding RISC-V&rsquo;s
piece of the pie&rdquo;.</li>
<li>Experanto is designing a high-performance RISC-V core comparable to the best
IP alternatives. It is designing an energy-efficient RISC-V core for high
TeraFLOP computing needs. The goal is to make RISC-V more compelling than the
other high-end alternatives.</li>
<li>Will produce IP with human readable, synthesizable Verilog.</li>
<li>Esperanto is building the highest TeraFLOPS per Watt machine learning
computing system, and it will be based on the RISC-V ISA</li>
<li>ET-Maxion will be the highest single thread performance 64-bit RISC-V
processor. Starting from BOOM v2, but expect substantial changes. Optimized
for 7nm CMOS. This will be used in Esperanto&rsquo;s products and made available as
a licensable core.</li>
<li>Second core is the ET-Minion. This is intended to do all the heavy floating
point work, with very high floating point throughput and energy efficiency.
This will be a 64-bit RISC-V core with vector extensions, an in-order
pipeline, and extra instruction extensions for machine learning. Also have
multiple hardware threads of execution. Like the ET-Maxion, this will be used
in Esperanto products and available as a licensable core.</li>
<li>Putting these together in a product: Esperanto&rsquo;s AI supercomputer on a chip.
16 64-bit ET-Maxion RISC-V cores with private L1 and L2 caches, 4096 64-bit
ET-Minion RISC-V cores each with their own vector floating point unit,
hardware accelerators, Network on Chip to allow processors to reside in the
same address space, multiple levels of cache, etc.</li>
<li>Other companies are proposing special purpose hardware for machine learning
using proprietary instruction sets. Esperanto want to base all processing on
RISC-V, adding instruction extensions and hardware accelerators where
necessary.</li>
<li>Also looked at using RISC-V for graphics. Wrote a shader compiler that can
generate RISC-V compilers, and the code to distribute the workload across
thousands of cores.</li>
<li>Argue that proprietary, custom instruction sets are a bad choice. Instead,
make general purpose RISC-V processors with domain specific extensions when
needed.</li>
</ul>

<h2 id="andes-extended-features-dr-chuan-hua-chang:c75429522933c8c4c55bd90283936952">Andes Extended Features: Dr Chuan-Hua Chang</h2>

<ul>
<li>Andes Technology is a Taiwan-based CPU IP company with over 2 billion
Andes-Embedded SoCs shipped in diverse applications.</li>
<li>Have extended the RISC-V architecture in the V5m with:

<ul>
<li>Vectored interrupts and priority-based preemptive interrupts for the PLIC</li>
<li>StackSafe features</li>
<li>Exception redirection to the debuggers</li>
</ul></li>
<li>The V5m ISA includes

<ul>
<li>Andes Perfomance extension</li>
<li>Optional Andes DSP extension</li>
<li>Optional Andes Custom extension</li>
</ul></li>
<li>For the vectored PLIC, vector table entry 0 contains exceptions and local
interrupts except &ldquo;external interrupt&rdquo;. Vector table entry 1 and above
contains external interrupts from the PLIC. The PLIC interrupt ID is
transmitted directly from PLIC to a hart.</li>
<li>The extended PLIC saves over 30 instructions for dispatch and software
preemption overhead.</li>
<li>StackSafe monitors the SP register value to detect stack pointer overflow
and underflow, and for recording the maximum observed stack size.</li>
<li>Andes ISA extensions add

<ul>
<li>GP-implied load/store instructions with a larger immediate range.</li>
<li>Compare an operand with a small constant and branch</li>
<li>Instructions for zero/sign-extensions</li>
<li>CoDense: code size compression instructions</li>
</ul></li>
<li>The Andes DSP ISA extension features over 130 instructions, using only GPRs.
Introduces a range of SIMD instructions, zero-overhead loops, and 64-bit
signed/unsigned addition and subtractions, and signed/unsigned multiplication
and addition.

<ul>
<li>See 50% cycle reduction for the Helix MP3 decoder, and 80.1% cycle
reduction for the G.729 codec.</li>
</ul></li>
<li>Andes Custom Extension (ACE) provides a framework to facilitate custom
instruction design and implementation.</li>
</ul>

<h2 id="customisation-of-a-risc-v-processor-to-achieve-dsp-performance-gain-marcela-zachariasova:c75429522933c8c4c55bd90283936952">Customisation of a RISC-V processor to achieve DSP performance gain: Marcela Zachariasova</h2>

<ul>
<li>Codasip studio is a processor development environment which takes a high
level description of a processor and automatically generates software tool,
RTL, and verification environments.</li>
<li>Take one of Codasip&rsquo;s Berkelium RISC-V cores as the starting point.</li>
<li>Configure the core by enabling/disabling ISA extensions as desired. You can
also define new instructions, driven by profiling information.</li>
<li>Case study: audio processing solution for IoT (developed with Microsemi).</li>
<li>Ultimately, saw a 13.62x speedup for a 2.43x area overhead vs RV32IM.</li>
</ul>

<h2 id="freedom-u500-linux-capable-1-5gh-quad-core-rv64gc-soc-jack-kang:c75429522933c8c4c55bd90283936952">Freedom U500, Linux-capable, 1.5GH quad-core RV64GC SoC: Jack Kang</h2>

<ul>
<li>Freedom Unleashed 500: 250M+ transistors, TSMC 28nm, high-performance
integrated RISC-V SoC, U54MC RISC-V CPU Core Complex</li>
<li>1.5GHz+ SiFive E51/U53 CPU. 1xE51 (16KB L1I$, 8KB DTIM), 4 x U54. 32KB L1I$,
32KB L1D$.</li>
<li>All five cores in a coherent system with 2MB L2$.</li>
<li>Development board available in Q12018.</li>
<li>Feature GbE, DDR3/4, and ChipLink (a serialized chip-to-chip TileLink
interconnect).</li>
<li>The E51 core is a 64-bit, 1.5GHz CPU &ldquo;minion core&rdquo;.</li>
<li>Coherent, 2MB 16-way L2 subsystem.</li>
<li>Single U54 core-only area 0.224mm2, single U53 core complex area 0.538mm2
(including 32KB/32KB L1 cache). 1.7 DMIPS/MH, 2.75 CoreMark/MHz.</li>
<li>HiFive Unleashed will have the SiFive Freedom Unleashed 500 SoC connected to
a Microsemi PolarFire FPGA, Provide USB and HDMI via the FPGA, as well as
PCIe. Available Q1&rsquo;2018.</li>
<li>HiFive Unleashed Early Access Program: give early access to FPGA-based
prototypes (now) and development boards (soon). To get access, email
info@sifive.com.</li>
</ul>

<h2 id="revolutionizing-risc-v-based-application-design-possibilities-with-globalfoundries-gregg-bartlett:c75429522933c8c4c55bd90283936952">Revolutionizing RISC-V based application design possibilities with GlobalFoundries: Gregg Bartlett</h2>

<ul>
<li>GlobalFoundries is the only foundry that is a RISC-V Foundation member. See
that the RISC-V approach is a good match for GlobalFoundries.</li>
<li>For the last year, have been engaged in applications where RISC-V processors
are showing up. DNN accelerators, cluster computing, automotive/embedded SoCs,
X86/GPU co-processors.</li>
<li>Argue foundry technology allows differentiated customer solutions. e.g.
22FDX and 12FDX.</li>
<li>22FDX is targeted to serve segments such as mobility, IoT, RF, and
automotive.</li>
<li>FDXcellerator program features multiple RISC-V cores, as well as LPDDR4,
MIPI etc.</li>
<li>Partnered with SiFive (E31+E51), Reduced Energy Microsystems, Andes, ETH
Zurich / University of Bologna (PULP), Berkeley Labs, IIT Chennai.</li>
<li>For the SiFive partnership, no cost to customers for E31/E51 cores until
production starts.</li>
</ul>

<h2 id="risc-v-llvm-towards-a-production-ready-llvm-based-toolchain-alex-bradbury:c75429522933c8c4c55bd90283936952">RISC-V LLVM. Towards a production-ready LLVM-based toolchain: Alex Bradbury</h2>

<ul>
<li>I was the presenter, so no notes right now.</li>
</ul>

<h2 id="a-risc-v-java-update-martin-maas:c75429522933c8c4c55bd90283936952">A RISC-V Java update: Martin Maas</h2>

<ul>
<li>Jikes RVM now runs full JDK6 applications, including the Decapo benchmark
suite. Passes the Jikes RVM core test suite. About 15000 lines of code.</li>
<li>Managed languages have been under-represented in computer architecture
research for quite some time.</li>
<li>Challenges: long running on many cores, concurrent tasks, fine-grained
interactions. Difficult fit for many common simulation approaches, e.g. Qemu
or Gem5.</li>
<li>Instead, we can run managed workloads on real RISC-V hardware in FPGA-based
simulation to enable modifying the entire stack.</li>
<li>By modifying the hardware, we can do fine-grained tracing without perturbing
the software being tested.</li>
<li>Can explore the interaction with the memory system, e.g. DRAM row misses
encountered during garbage collection.</li>
<li>This will allow a wide range of research that was difficult without this
infrastructure.</li>
<li>Have the Jikes Research VM (baseline JIT, no optimising JIT). Can run
OpenJDK Hotspot JVM with the Zero (interpreter) backend, but no
high-performance JIT compiler port yet. Help needed!</li>
<li>The RISC-V Foundation has launched the J extension working group today, to
better support managed-language support to RISC-V.</li>
</ul>

<h2 id="microprobe-an-open-source-microbenchmark-generator-ported-to-the-risc-v-isa-schuyler-eldridge:c75429522933c8c4c55bd90283936952">MicroProbe. An open source microbenchmark generator ported to the RISC-V ISA: Schuyler Eldridge</h2>

<ul>
<li>Not yet open source, but in the process of releasing it.</li>
<li>Why make microbenchmarks? Might want to study worst case power consumption,
look for performance bugs, determine if the design is reliable, &hellip; But
writing microbenchmarks is a labour-intensive process.</li>
<li>MicroProbe has the user write microbenchmark generation policies. The
framework then produces benchmarks according to those policies.</li>
<li>The target definition (ISA, microarchitecture, environment) is written using
YAML. Code generation and generation policies are written using Python.</li>
<li>MicroProbe uses riscv-meta from Michael Clark.</li>
<li>The user describes a microbenchmark as transforms over an intermediate
representation (IR) for describing benchmarks.</li>
</ul>

<h2 id="lauterbach-debug-support-for-risc-v-bob-kupyn:c75429522933c8c4c55bd90283936952">Lauterbach debug support for RISC-V: Bob Kupyn</h2>

<ul>
<li>Lauterbach is solely focused on hardware and software debug tools. All
design, development and manufacture is done in Munich.</li>
<li>Claim the widest range of supported microprocessors in the market.</li>
<li>More than 100k installed Lauterbach debuggers, estimate 40% of the market.</li>
<li>Have a RISC-V JTAG debugger. Currently just run-control, awaiting a stable
trace debug spec.</li>
<li>Trace32 debugger supports all the features you&rsquo;d expect. The RISC-V port
supports RV32 and RV64. In the future, want to add trace support and
Linux/Target OS awareness.</li>
<li>In the initial release, support SiFive Coreplex E31 and E51.</li>
</ul>

<h2 id="j-link-debug-probe-now-available-for-risc-v-paul-curtis:c75429522933c8c4c55bd90283936952">J-link debug probe now available for RISC-V: Paul Curtis</h2>

<ul>
<li>J-Link aims to be the &ldquo;ultimate debug probe&rdquo;. Supporting ARM, Mips, RX,
8051, and now RISC-V.</li>
<li>J-Link is open in the sense you can incorporate it into your product using
the J-Link SDK.</li>
<li>J-Link is &ldquo;intelligent&rdquo;, eliminating round-trip-time over USB or IP using
kernels in the debug adapter.</li>
<li>Over 600k units sold.</li>
<li>Also have Embedded Studio, other products.</li>
</ul>

<h2 id="porting-the-threadx-rtos-to-risc-v-john-carbone:c75429522933c8c4c55bd90283936952">Porting the ThreadX RTOS to RISC-V: John Carbone</h2>

<ul>
<li>ThreadX in production since 1997.</li>
<li>Small footprint, priority-based, fully preemptive RTOS with a single linear
address space.</li>
<li>Has advanced features like preemption-threshold scheduling, real-time event
trace, memory-protected modules.</li>
<li>Ported with co-operation from Mirosemi, ran on the Smartfusion2 Creative
Development Board.</li>
<li>Anticipate commercial availability for RISC-V before the end of 2017.</li>
</ul>

<h2 id="xbgas-a-bridge-proposal-for-rv128-and-hpc-john-leidel:c75429522933c8c4c55bd90283936952">xBGAS. A bridge proposal for RV128 and HPC: John Leidel</h2>

<ul>
<li>Extended Base Global Address Space (xBGAS)</li>
<li>Want to provide extended addressing capabilities without ruining the base
ABI.</li>
<li>Extended addressing must not specifically rely upon any one virtual memory</li>
<li>xBGAS is not a direct replacement for RV128.</li>
<li>See a variety of potential application domains.</li>
<li>HPC-PGAS: traditional message passing has a tremendous amount of overhead.
There are a range of low-latency PGAS runtimes, but little hardware/uarch
support.</li>
<li>Add extended (eN) register that map to base general registers. These are
manually utilized via extended load/store/move instructions.</li>
<li>You only get access to the extended address space when using the new
extended addressing instructions.</li>
<li>ISA extensions: base integer load/store, raw integer load/store, address
management (explicitly read/write the extended registers).</li>
<li>No support for things like atomics currently. (Question for the community:
how to define extensions to extensions?)</li>
<li>A number of outstanding issues with the ABI and calling convention. How to
link base RISC-V objects with objects containing extended addressing? Howe do
we address the caller/callee saved state with extended registers? What about
debugging and debugging metadata.</li>
<li>The software part of this is being led by the Data Intensive Scalable
Computing Lab at Texas Tech. Have a prototype implementation in LLVM.</li>
<li>Hardware part of the effort taking place at Tactical Computing Labs, LBNL
and MIT. Looking at pipelined and accelerator-based implementations.</li>
<li>The current spec is <a href="https://github.com/tactcomplabs/xbgas-archspec">available
here</a>. Comments and
collaborators are encouraged!</li>
</ul>

<h2 id="extending-the-16-gpr-standard-beyond-rv32e-mitch-hayenga:c75429522933c8c4c55bd90283936952">Extending the 16 GPR standard beyond RV32E: Mitch Hayenga</h2>

<ul>
<li>Motivation: Register file area/power/latency is critical to any processor.
Large register files help with static code scheduling, but wide issue
out-of-order processors have the potential to hide register spill latency and
issue bandwidth.</li>
<li>There are a number of commercially available cores that only offer 16
double-precision floating point registers.</li>
<li>Want to see the 16GPR option being orthogonal just like any other ISA
variant (RV32E currently can&rsquo;t be combined with the F and D extensions).</li>
<li>Reduced the available registers to x0-x15 and f0-f15. Modified GCC and glibc
and used gem5 with the Coremark/Dhrystone/Whetstone/Spec2006 benchmarks.</li>
<li>For the simple benchmarks, saw a 6-8% increase in static code size. Smaller
increase in dynamic instructions (and Whetstone saw a reduction). Saw in-order
execution time impacted, but much smaller impact for the out-of-order designs.</li>
<li>For SPECInt, saw (very) slightly improved code density and execution time.<br />
In perlbench this was primarily due to reduced function call overhead.</li>
<li>The impact was more negative for SPECFP.</li>
<li>Architectural overheads limit the viable design space of multithreaded
out-of-order CPUs.</li>
<li>New potential designs:

<ul>
<li>Dual-threaded, small window out-of-order CPUs (~20 instruction windows).
This is impractical with the current RISC-V register file size requirements</li>
<li>Large, high-IPC, many threaded CPU designs.</li>
</ul></li>
</ul>

<h2 id="using-pyrope-to-create-transformable-risc-v-architectures-haven-skinner:c75429522933c8c4c55bd90283936952">Using Pyrope to create transformable RISC-V architectures: Haven Skinner</h2>

<ul>
<li>Hardware design is difficult. You need multiple codebases (cycle accurate,
high level simulation, verification reference model). Also need to adjust
pipeline stages and verify the hardware.</li>
<li>A new HDL (Pyrope) can help!</li>
<li>Fluid pipelines are the &ldquo;hammer&rdquo; used to address design complexity. Fluid
pipeline transformations change the number of stages as part of the compile
flow.</li>
<li>A fluid pipeline has valid/stop signals, and pipeline stages should tolerate
random delays.</li>
<li>Collapsing stages was useful in order to build an emulator out of a RISC-V
fluid core. Can also change the number of pipeline stages automatically, and
perform formal verification.</li>
<li>For a Verilog implementation, saw 2MIPS when compiling with Verilator. When
collapsing fluid pipelines to produce a fast emulator, saw 6MIPS. Spike
achieves around 12 MIPS.</li>
<li>Compared synthesis results of the fluid pipelines vs a range of open source
RISC-V cores.</li>
<li>For &ldquo;fluid verification&rdquo;, can collapse the stages in a RISC-V core, then
verify against a trivial single stage RISC-V core. Used yosys to do this.</li>
</ul>

<h2 id="performance-isolation-for-multicore-within-labeled-risc-v-zihao-yu:c75429522933c8c4c55bd90283936952">Performance isolation for multicore within labeled RISC-V: Zihao Yu</h2>

<ul>
<li>In multi-core architectures, core share resources such as L3, memory, and
I/O. This can cause uncertainties and QoS violations.</li>
<li>Take inspiration from labeled networks and try to apply to computer
architecture. Describe the Labeled von Neumann Architecture (LvNA).</li>
<li>Each request has a label, each label is correlated with a
process/thread/variable, labels are propagated across the whole machine, and
software-defined control logic is used to provide different service for
different labeled groups.</li>
<li>Proposed PARD (ASPLOS 2015). Programmable Architecture for
Resourcing-on-Demand.

<ul>
<li>Add a label register, allocate a label for each VM, attach a label to each
request, and add label-based programmable control logic.</li>
</ul></li>
<li>LvNA + RISC-V = Labeled RISC-V</li>
<li>Saw less than 3% overhead in terms of code, less than 5% resource overhead,
and no performance overheads for critical apps.</li>
<li>Plan to tape out with TSMC 40nm next year.</li>
</ul>

<h2 id="a-practical-implementation-of-a-platform-level-interrupt-controller-plic-richard-herveille:c75429522933c8c4c55bd90283936952">A Practical Implementation of a Platform Level Interrupt Controller (PLIC): Richard Herveille</h2>

<ul>
<li>PLIC design goals: easy integration with external bus interfaces, be fully
compliant, and very flexible. Should work from small microcontrollers all the
way up to large server applications.</li>
<li>The deign flexibility may result in management complexity. Potentially
hundreds or thousands of registers in a memory mapped management interface. So
try to define a management interface that minimises the memory map.</li>
<li>Create the memory map dynamically based on parameters given to the IP core.<br />
The register arrangement and documentation is automated.</li>
<li>See the <a href="https://roalogic.com">Roa Logic website</a>.</li>
</ul>

<h2 id="open-source-rtos-ports-on-risc-v-nitin-deshpande:c75429522933c8c4c55bd90283936952">Open source RTOS ports on RISC-V: Nitin Deshpande</h2>

<ul>
<li>Ported FreeRTOS, MyNewt, and Huawei LitOS.</li>
<li>FreeRTOS: 32-bit version running on a RISC-V soft processor, 64-bit
currently runs on Spike.</li>
<li>MyNewt: RISC-V support was already available, added the BSP and MCU/HAL
support.</li>
<li>LiteOs: ported the kernel, BSP, and HAL. Already merged into upstream LiteOS
GitHub.</li>
<li>Had a positive experience with RISC-V.</li>
<li>Mi-V is an ecosystem that aims to accelerate the adoption of RISC-V.</li>
</ul>

<h2 id="risc-v-poster-preview:c75429522933c8c4c55bd90283936952">RISC-V poster preview</h2>

<ul>
<li>This is too rapid fire to summarise, sorry!</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>GSoC 2017 student report: core lockstep for minion cores</title><link>https://www.lowrisc.org/blog/2017/10/gsoc-2017-student-report-core-lockstep-for-minion-cores/</link><guid>https://www.lowrisc.org/blog/2017/10/gsoc-2017-student-report-core-lockstep-for-minion-cores/</guid><pubDate>Thu, 05 Oct 2017 19:45:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>This year, as part of <a href="https://developers.google.com/open-source/gsoc/">Google Summer of
Code</a> we had the pleasure of
working with Nikitas Chronas. Alongside his degree studies, Nikitas had become
involved with the <a href="https://libre.space/">Libre Space Foundation</a> and developed
a strong interest in the possibility of open source hardware in
<a href="https://en.wikipedia.org/wiki/CubeSat">CubeSats</a>. Fault tolerance of some
sort is important for harsh environments, and Nikitas worked to add fault
tolerance through the implementation of <a href="https://en.wikipedia.org/wiki/Lockstep_(computing)">core
lockstep</a> for the
PULPino-based minion
core subsystem. This was a really successful project which ended up
making contributions in areas beyond the core lockstep focus:
documentation, code quality, support for the Arty FPGA development board, and
even prototyping a code generation mechanism. See the <a href="https://www.lowrisc.org/docs/gsoc-2017/core-lockstep/">detailed write-up</a>
for all the details, and below for the all-important blinky lights demo.</p>

<iframe src="https://giphy.com/embed/26vIg6cZFMWvi6AbS" width="480" height="401" frameBorder="0" class="giphy-embed" allowFullScreen></iframe>
 ]]></description></item><item><title>Moving RISC-V LLVM forwards</title><link>https://www.lowrisc.org/blog/2017/09/moving-risc-v-llvm-forwards/</link><guid>https://www.lowrisc.org/blog/2017/09/moving-risc-v-llvm-forwards/</guid><pubDate>Wed, 27 Sep 2017 17:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>A high quality, upstream RISC-V backend for LLVM is perhaps the most
frequently requested missing piece of the RISC-V software ecosystem. This
blog post provides an update on the rapid progress we&rsquo;ve been making towards
that goal, outlines next steps and upcoming events, and tries to better
explain the approach that we&rsquo;re taking.
As always, you
can track status <a href="https://www.lowrisc.org/llvm/status/">here</a> and find the code
<a href="https://github.com/lowRISC/riscv-llvm">here</a>.</p>

<h2 id="status:b7c83479950d2bfc2cec7921b78c2ef0">Status</h2>

<p>I&rsquo;ve been able to make substantial progress since the <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-August/116709.html">last
update</a>.</p>

<h3 id="rv32:b7c83479950d2bfc2cec7921b78c2ef0">RV32</h3>

<p>100% of the GCC torture suite passes for RV32I at -O0, -O1, -O2, -O3, and -Os
(after masking gcc-only tests). MC-layer (assembler) support for RV32IMAFD has
now been implemented, as well as code generation for RV32IM.</p>

<h3 id="rv64:b7c83479950d2bfc2cec7921b78c2ef0">RV64</h3>

<p>This is the biggest change versus my last update. LLVM recently gained support
for parameterising backends by register size, which allows code duplication to
be massively reduced for architectures like RISC-V. As planned, I&rsquo;ve gone
ahead and implemented RV64I MC-layer and code generation support making use of
this feature. I&rsquo;m happy to report that 100% of the GCC torture suite passes
for RV64I at O1, O2, O3 and Os (and there&rsquo;s a single compilation failure at
O0). I&rsquo;m very grateful for Krzysztof Parzyszek&rsquo;s (QUIC) work on variable-sized
register classes, which has made it possible to parameterise the backend on
XLEN in this way. That LLVM feature was actually motivated by requirements of
the Hexagon architecture - I think this is a great example of how we can all
benefit by contributing upstream to projects, even across different ISAs.</p>

<h3 id="other-activities:b7c83479950d2bfc2cec7921b78c2ef0">Other activities</h3>

<ul>
<li>Community members Luís Marques and David Craven have been experimenting with
D and Rust support respectively.</li>
<li>Andes Technology have started working to contribute to this effort, and are
putting together patches for compressed instruction set support. This is a
really positive move and I hope others will follow their lead.</li>
</ul>

<h3 id="development-stats:b7c83479950d2bfc2cec7921b78c2ef0">Development stats</h3>

<ul>
<li>The &lsquo;reference&rsquo; <a href="https://github.com/lowRISC/riscv-llvm">patch queue</a> consists
of 48 patches, modifying 128 files and inserting over 11500 lines to the LLVM
and Clang codebases. Close to 50% of these lines are new tests.</li>
<li>Other activities:

<ul>
<li>8 committed patches to LLVM in areas other than lib/Target/RISCV
(cleanups, support code, documentation improvements, bug fixes) with 5 more
making their way through the review process.</li>
<li>2 GCC/binutils bugs reported</li>
<li>RISC-V <a href="https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md">psABI
doc</a>:
Authored 7 merged commits, 13 issues filed.</li>
</ul></li>
</ul>

<p>I&rsquo;d like to thank <a href="https://github.com/lowRISC/riscv-llvm#credits">everyone</a>
who has contributed code review, feedback, or suggestions so far, as well as
our industrial sponsor.</p>

<h2 id="approach-and-philosophy:b7c83479950d2bfc2cec7921b78c2ef0">Approach and philosophy</h2>

<p>As enthusiastic supporters of RISC-V, I think we all want to see a huge range
of RISC-V core implementations, making different trade-offs or targeting
different classes of applications. But we <em>don&rsquo;t</em> want to see that variety in
the RISC-V ecosystem result in dozens of different vendor-specific compiler
toolchains and a fractured software ecosystem. Unfortunately most work on LLVM
for RISC-V has been invested in private/proprietary code bases or short-term
prototypes. The work described in this post has been performed out in the open
from the start, with a strong focus on code quality, testing, and on moving
development upstream as quickly as possible - i.e. a solution for the long term.</p>

<p>My implementation approach has been to first work towards a cleanly designed
and well tested RV32I baseline compiler. Once the fundamentals are solid, it
is <em>significantly</em> easier to add in new features, optimisations, or indeed
customisations for different RISC-V variants. This careful approach has
enabled the rapid progress of the past few weeks. I would summarise this
approach as:</p>

<ol>
<li>Ensuring (to the extent possible) that correct code is always generated for
a simple RV32I baseline</li>
<li>Expand that baseline to support more RISC-V ISA variants (RV{32,64}IMA and
later FD)</li>
<li>Push forwards on optimisations (generated code quality) and compiler
feature support. Part of this work is moving to larger scale test programs and
benchmarks in order to maintain confidence about the correctness of generated
code.</li>
</ol>

<p>This project is currently in the process of moving from point 2) to point 3)
on the list above. As it stands, you will benefit from LLVM&rsquo;s many middle-end
optimisations, but the final code generation stage has seen little work
focused on the performance of generated code. With a high quality base now in
place, adding these optimisations can be done relatively easily.</p>

<p>If you want to see first-class support for RISC-V in LLVM, now is the time to
get involved and help make it happen.</p>

<h2 id="roadmap-and-upcoming-events:b7c83479950d2bfc2cec7921b78c2ef0">Roadmap and upcoming events</h2>

<p>My aim is to have Clang and LLVM developed to serve as a competitive
alternative to GCC on RISC-V by the end of the calendar year. If the RISC-V
community works together, this is an achievable goal.</p>

<p>My near-term goals are:</p>

<ul>
<li>Expand testing for RV64. There are rather few RV64 unit tests right now
because parameterising the backend by XLEN mostly &ldquo;just worked&rdquo;.</li>
<li>Go through the implementation again (particularly recently added code) to
look for further cleanup or refactoring opportunities, then propose to merge
it upstream.</li>
<li>Once I&rsquo;m happy with the implementation approach for the most recently added
features, move the 5.0-based
<a href="http://github.com/lowrisc/riscv-llvm-integration">riscv-llvm-integration</a>
tree forwards.</li>
<li>Review patches from contributors such as Andes and help to support language
port efforts.</li>
</ul>

<p>Focus areas after that include:</p>

<ul>
<li>Clang toolchain driver, MAFD codegen and ABI support</li>
<li>Benchmarking vs RISC-V GCC and generated code quality improvements</li>
<li>Documentation, expanded test cases, and improved compiler testing tooling</li>
</ul>

<p>I&rsquo;ve mapped out a number of TODO items
<a href="https://github.com/lowRISC/riscv-llvm/issues">here</a>.</p>

<p>I&rsquo;m pleased to report that my proposal for a RISC-V &ldquo;birds of a feather&rdquo;
session at the <a href="http://llvm.org/devmtg/2017-10/#bof4">upcoming LLVM Dev
Meeting</a> (Oct 18th) was accepted. You
should definitely attend this event if you are an LLVM developer working on an
out-of-tree RISC-V backends or are looking to get involved (representatives
from several companies in that position are already confirmed as attending).
We&rsquo;re also looking to run a longer working/hacking session the day before, at
a San Jose location. More details on both events will be circulated shortly.</p>

<h2 id="faq:b7c83479950d2bfc2cec7921b78c2ef0">FAQ</h2>

<h3 id="do-you-care-about-performance-of-generated-code-and-code-size:b7c83479950d2bfc2cec7921b78c2ef0">Do you care about performance of generated code and code size?</h3>

<p>Like any compiler developer, of course. Starting with a solid and well tested
base is the best way of achieving those aims. We&rsquo;re now in a position where we
can push forwards on these fronts, which will will soon become a primary focus
of this development effort.</p>

<h3 id="i-have-a-risc-v-llvm-fork-which-works-for-me-why-should-i-care-about-an-upstream-backend:b7c83479950d2bfc2cec7921b78c2ef0">I have a RISC-V LLVM fork which works for me, why should I care about an upstream backend?</h3>

<p>This is ultimately a question about long-term maintenance and sharing the
support burden with others in the RISC-V ecosystem. By working together and
pooling our development efforts, we can unlock the benefits of the open source
approach. Contributing to this effort is almost definitely the right long-term
choice for your project. If you want to discuss how to contribute, please drop
me an email or come along to the upcoming birds of a feather session.</p>

<h3 id="what-is-the-difference-between-this-and-other-risc-v-llvm-efforts:b7c83479950d2bfc2cec7921b78c2ef0">What is the difference between this and other RISC-V LLVM efforts?</h3>

<p>This effort is focused on high code quality, long term maintainability, and in
getting development merged in to upstream LLVM. Andes have recently released a
private development tree to the public. That tree was was based on an early
version of the lowRISC patchset, but diverged significantly in terms of
implementation approach. Andes are now working to submit patches to this
effort.</p>

<h3 id="who-are-you:b7c83479950d2bfc2cec7921b78c2ef0">Who are you?</h3>

<p>I (Alex Bradbury) am a co-founder and director of lowRISC CIC, where this
development work has been taking place. I have been developing LLVM backends
for the past seven years, and am now upstream code owner for the RISC-V
backend. If you&rsquo;re interested in LLVM, you are hopefully already familiar with
my <a href="http://llvmweekly.org/">LLVM Weekly</a> newsletter.</p>

<h3 id="why-is-lowrisc-interested-in-llvm:b7c83479950d2bfc2cec7921b78c2ef0">Why is lowRISC interested in LLVM?</h3>

<p>lowRISC is a not-for-profit created to push forward open source hardware by
developing a secure, open, and flexible SoC design. Enabling custom hardware
and derivative designs is about much more than shipping RTL with an open
source license - hardware is of little use without the software infrastructure
in place to support it. A high quality and easy to modify LLVM backend is
important for potential lowRISC adopters, but also benefits our own hardware
development efforts. Specifically, we will be building the software component
of our tagged memory mechanisms on top of LLVM. If our mission sounds
interesting to you, there&rsquo;s good news - <a href="https://www.lowrisc.org/blog/2017/09/were-hiring-work-on-making-open-source-hardware-a-reality/">we&rsquo;re
hiring</a>.</p>

<h3 id="who-do-i-contact-to-discuss-further-sponsoring-this-effort:b7c83479950d2bfc2cec7921b78c2ef0">Who do I contact to discuss further sponsoring this effort?</h3>

<p>If your company would like to see lowRISC&rsquo;s work on RISC-V LLVM be sustained
or expanded through 2018, then contributing development time and/or
sponsorship is the best way to do this. Please contact asb@lowrisc.org to
discuss further.</p>
 ]]></description></item><item><title>lowRISC tagged memory OS enablement</title><link>https://www.lowrisc.org/blog/2017/09/lowrisc-tagged-memory-os-enablement/</link><guid>https://www.lowrisc.org/blog/2017/09/lowrisc-tagged-memory-os-enablement/</guid><pubDate>Tue, 19 Sep 2017 14:45:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>This summer, we were fortunate enough to have Katherine Lim join the lowRISC
team at the University of Cambridge Computer Laboratory as an intern.
Katherine&rsquo;s focus was on operating system and software enabled for lowRISC&rsquo;s
tagged memory, building upon our
<a href="https://www.lowrisc.org/docs/minion-v0.4/">most recent milestone release</a>.
As Katherine&rsquo;s <a href="https://www.lowrisc.org/docs/tagged-memory-os-enablement-internship-2017/">detailed write-up</a> demonstrates,
it&rsquo;s been a very productive summer.</p>

<p>The goal of this internship was to take the lowRISC hardware release, and
demonstrate kernel support and software support for the hardware tagged memory
primitives. This includes support for context-switch of the <code>tagctrl</code> register
used to configure tag rules, maintaining tags in pages upon copy-on-write,
delivering tag exceptions to user space, loading tags from ELF binaries, and
more. It culminated in a demonstration that pulls these various pieces of work
together, showing how tagged memory can be used to mark valid branch targets.
Read the <a href="https://www.lowrisc.org/docs/tagged-memory-os-enablement-internship-2017/">report</a> for full
details.</p>

<p>We believe there is a rich design space in hardware support for tagged memory
and tag-based software policies. This operating system enablement work is an
important part of exploring that space, and in making it easier for other
groups to do the same.</p>

<p>If working on problems like this sounds interesting to you, there&rsquo;s good news
- <a href="https://www.lowrisc.org/blog/2017/09/were-hiring-work-on-making-open-source-hardware-a-reality/"><strong>we&rsquo;re hiring</strong></a>.</p>

<p><em>Alex Bradbury and Katherine Lim</em></p>
 ]]></description></item><item><title>We&#39;re hiring! Work on making open source hardware a reality</title><link>https://www.lowrisc.org/blog/2017/09/were-hiring-work-on-making-open-source-hardware-a-reality/</link><guid>https://www.lowrisc.org/blog/2017/09/were-hiring-work-on-making-open-source-hardware-a-reality/</guid><pubDate>Mon, 18 Sep 2017 08:15:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>We are looking for a talented hardware engineer to join the lowRISC team and
help make our vision for an open source, secure, and flexible SoC a reality.
<a href="https://lowrisc.workable.com/j/DBAC61322F">Apply now</a>!</p>

<p>lowRISC C.I.C. is a not-for-profit company that aims to demonstrate, promote
and support the use of open-source hardware. The lowRISC project was
established in 2014 with the aim of bringing the benefits of open-source to
the hardware world. It is working to do this by producing a high quality,
secure, open, and flexible System-on-Chip (SoC) platform. lowRISC C.I.C. also
provides hardware and software services to support the growing RISC-V
ecosystem. Our expertise includes the LLVM Compiler, hardware security
extensions and RISC-V tools, hardware and processor design.</p>

<p>The successful candidate will be interested in computer architecture and
hardware design. The primary focus of the role will be the development of the
lowRISC SoC platform, which will involve work to evaluate and extend our
current design including our general-purpose tagged-memory system. lowRISC is
an ambitious project with a small core team, so you will be heavily involved
in the project&rsquo;s development direction. This role will involve frequent work
with external contributors and collaborators. While much of the work will be
at the hardware level the post will offer experience of the full
hardware/software stack, higher-level simulation tools and architectural
design issues.</p>

<p>Some practical experience of hardware design with a HDL such as
Verilog/SystemVerilog is essential, as is a good knowledge of the HW/SW stack.
Ideally, candidates will also have experience or demonstrated interest in some
of: SoC design, large-scale open source development, hardware or software
security, technical documentation, board support package development and
driver development. Industrial experience and higher degree levels are valued,
but we would be happy to consider an enthusiastic recent graduate with a
strong academic record.</p>

<p>Informal enquires should be made to Alex Bradbury <a href="mailto:asb@lowrisc.org">asb@lowrisc.org</a>.</p>
 ]]></description></item><item><title>Building upstream RISC-V GCC&#43;binutils&#43;newlib: the quick and dirty way</title><link>https://www.lowrisc.org/blog/2017/09/building-upstream-risc-v-gccbinutilsnewlib-the-quick-and-dirty-way/</link><guid>https://www.lowrisc.org/blog/2017/09/building-upstream-risc-v-gccbinutilsnewlib-the-quick-and-dirty-way/</guid><pubDate>Tue, 05 Sep 2017 14:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>There are a number of available options for building a RISC-V GCC toolchain.
You might use the build system from the
<a href="https://github.com/riscv/riscv-tools">riscv/riscv-tools repository</a>, or
investigate toolchain generators such as
<a href="http://crosstool-ng.github.io/">crosstool-ng</a>. However in the case of
riscv-tools, it&rsquo;s not always clear how this corresponds to the code in the
relevant upstream projects. When investigating a potential bug, you often just
want to build the latest upstream code with as little fuss as possible. For
distribution purposes you&rsquo;d probably want to perform a proper multi-stage
build, but for a quick test you might find the following recipe useful:</p>

<pre><code>git clone --depth=1 git://gcc.gnu.org/git/gcc.git gcc
git clone --depth=1 git://sourceware.org/git/binutils-gdb.git
git clone --depth=1 git://sourceware.org/git/newlib-cygwin.git
mkdir combined
cd combined
ln -s ../newlib-cygwin/* .
ln --force -s ../binutils-gdb/* .
ln --force -s ../gcc/* .
mkdir build
cd build
../configure --target=riscv32-unknown-elf --enable-languages=c \
--disable-shared --disable-threads --disable-multilib --disable-gdb \
--disable-libssp --with-newlib \
--with-arch=rv32ima --with-abi=ilp32 --prefix=$(pwd)/built
make -j$(nproc)
make install
</code></pre>

<p>This will produce a newlib toolchain targeting RV32IMA in the <code>built/</code>
subdirectory. When files are duplicated in the newlib, binutils and gcc
repositories, the gcc version takes precedence.</p>

<p>Major credit to everyone who worked on getting these toolchain
ports upstream (Kito Cheng, Palmer Dabbelt, and others).</p>
 ]]></description></item><item><title>lowRISC 0-4 milestone release</title><link>https://www.lowrisc.org/blog/2017/06/lowrisc-0-4-milestone-release/</link><guid>https://www.lowrisc.org/blog/2017/06/lowrisc-0-4-milestone-release/</guid><pubDate>Fri, 09 Jun 2017 12:35:57 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>The <a href="https://www.lowrisc.org/docs/minion-v0.4/">lowRISC 0.4 milestone release</a>
is now available. The various changes are best described in our <a href="https://www.lowrisc.org/docs/minion-v0.4/">accompanying
documentation</a>, but in summary this
release:</p>

<ul>
<li>Moves forward our support for tagged memory by re-integrating the tag cache,
reducing overhead with a <a href="https://www.lowrisc.org/docs/minion-v0.4/tag_cache/">hierarchical scheme</a>.
This will significantly reduce caches misses caused by tagged memory accesses
where tags are distributed sparsely.</li>
<li>Integrates support for specifying and configuring <a href="https://www.lowrisc.org/docs/minion-v0.4/tag_core/">tag propagation and
exception behaviour</a>.</li>
<li>A <a href="http://www.pulp-platform.org/">PULPino</a> based &ldquo;minion core&rdquo; has been
integrated, and is used to provide peripherals such as the SD card
interface, keyboard, and VGA tex display (when using the Nexys4 DDR FPGA
development board).</li>
</ul>

<p>Please report any issues <a href="https://github.com/lowRISC/lowrisc-chip">on our GitHub
repository</a>, or discuss on our
<a href="http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org">mailing list</a>. As always, thank you to everyone who has contributed in any way - whether it&rsquo;s advice and feedback, bug reports, code, or ideas.</p>
 ]]></description></item><item><title>Apply now for GSoC 2017</title><link>https://www.lowrisc.org/blog/2017/03/apply-now-for-gsoc-2017/</link><guid>https://www.lowrisc.org/blog/2017/03/apply-now-for-gsoc-2017/</guid><pubDate>Mon, 27 Mar 2017 09:35:57 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>We are very grateful for being selected again to take part as a mentoring
organisation in the <a href="https://summerofcode.withgoogle.com/">Google Summer of
Code</a>, now for the third year running.
If you are a student who would like to be paid to work on open source during
the summer, then take a look at <a href="https://www.lowrisc.org/docs/gsoc-2017-ideas/">the lowRISC ideas
list</a> and
<a href="https://summerofcode.withgoogle.com/organizations/6271463900315648/">apply</a>.
The deadline for applications is 4pm UTC on April 3rd. We&rsquo;re always very interested in
ideas suggested by students, and encourage you to share them <a href="https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org">on our
discussion
list</a>
for feedback before making a proposal.</p>
 ]]></description></item><item><title>2017 NetFPGA Design Challenge</title><link>https://www.lowrisc.org/blog/2017/02/2017-netfpga-design-challenge/</link><guid>https://www.lowrisc.org/blog/2017/02/2017-netfpga-design-challenge/</guid><pubDate>Wed, 01 Feb 2017 14:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>As most of you know, the majority of full-time development on lowRISC takes
place at the University of Cambridge Computer Laboratory. However, we&rsquo;re far
from the only open source hardware activity at the University. Our colleagues
on the NetFPGA project have an open source design challenge that many readers
of this blog might be interested in. See the <a href="http://www.cl.cam.ac.uk/research/srg/netfpga/challenge2017/">design challenge
website</a>, or read
below for more details:</p>

<pre><code>We are pleased to announce the 2017 NetFPGA Design Challenge!

NetFPGA platforms are used by the networked systems community for close to 
a decade. The platforms enable researchers and instructors to build 
high-speed, hardware-accelerated networking systems. The platforms can be used 
by researchers to prototype advanced services for next-generation networked 
systems. By using Field Programmable Gate Arrays (FPGAs), NetFPGA enables new 
types of packet routing circuits to be implemented and detailed measurements 
of network traffic to be obtained.

The NetFPGA 2017 contest is a design challenge. The design teams are to 
produce a working implementation employing any HW and SW design methodology 
and targeting the NetFPGA SUME platform. The deadline for submissions is April 
13th, 2017. The winners will be announced at the NetFPGA Developers Summit 
(Thursday 20th - Friday, 21st April, 2017 Cambridge, UK).

Challenge: Lowest Latency Switch

Low latency devices are being increasingly used across a large number of 
applications. Low latency solutions are few, and are rarely open source. The 
goal of this challenge is to provide a usable, high performance, open source 
alternative to use by universities and organizations who need the flexibility 
of open source.  The systems will be evaluated using OSNT, an Open Source 
Network Tester. Test benches will be available online, for users to experiment 
and independently evaluate their design. The competition is open to students 
of all levels (undergraduate and postgraduate), as well as to non students. 
There is no need to own a NetFPGA SUME platform to take part in the 
competition although, clearly, development and testing will be made easier if 
you have access to this platform.  

Team Prizes:
First place: £500
Best students project: £500

The winning projects and runner ups will be invited to present their work 
at the NetFPGA Developers Summit 2017.  All challenge participants are keenly 
encouraged to attend the NetFPGA Developers Summit and are entitled to a 
reduced registration rate.

The design challenge prizes are generously 
supported by IMC http://www.imc.nl/
</code></pre>
 ]]></description></item><item><title>lowRISC Q&#43;A</title><link>https://www.lowrisc.org/blog/2016/12/lowrisc-qa/</link><guid>https://www.lowrisc.org/blog/2016/12/lowrisc-qa/</guid><pubDate>Fri, 09 Dec 2016 17:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>Yesterday, lowRISC triggered a lot of discussion when someone submitted it to
Hacker News. The <a href="https://news.ycombinator.com/item?id=13129076">comment
thread</a> became something of an
impromptu Q+A about our project direction and status. I thought it was worth
linking to it here and highlighting the discussion for a wider audience. If
you have any additional questions, then feel free to comment on this blog post
or else, as always, drop by our <a href="https://www.lowrisc.org/community/">mailing list</a>.</p>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>Fifth RISC-V Workshop: Day Two</title><link>https://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-two/</link><guid>https://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-two/</guid><pubDate>Wed, 30 Nov 2016 17:00:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>Today is the second day of the <a href="https://riscv.org/2016/10/5th-risc-v-workshop-agenda/">fifth RISC-V
workshop</a>. I&rsquo;ll be
keeping a semi-live blog of talks and announcements throughout the day.</p>

<h2 id="opensoc-system-architect-farzad-fatollahi-fard:030fe38319964b117c9ffaf378fa511a">OpenSoC System Architect: Farzad Fatollahi-Fard</h2>

<ul>
<li>Current architectures are wasteful. Only a small fraction of chip area goes
to computation.</li>
<li>For both GoblinCore and OpenHPC, ended up doing a lot of similar work to
achieve only a point design. Why not make a generator to avoid repeating the
same steps?</li>
<li>OpenSoC System Architect is a combination of multiple tools to form a
well-defined development flow for complex RISC-V SoCs</li>
<li>Supports standard RISC-V modules and custom extensions</li>
<li>It outputs pre-verified Chisel for the SoC, synthesisable Verilog, and an
LLVM compiler for the SoC</li>
<li>OpenSoC Fabric is an open-source, flexible, parameterised NoC generator. It
integrates with a wide variety of existing processors, as well as IO devices.</li>
<li>Created a &lsquo;CoreGen&rsquo; IR. It allows automatic generation of HDL
representations of the SoC and build LLVM compiler backend implementations of
the SoC and any extensions.</li>
<li>The IR is stored on disk in well-formed XML</li>
<li>What&rsquo;s next? Better support for Chisel3, more integration with existing
RISC-V tools and environment, frontend support to import existing
Chisel/Verilog/SystemVerilog. Also want CoreGen as a standalone IR</li>
<li>See the website at <a href="http://www.opensoc.community/">http://www.opensoc.community/</a></li>
</ul>

<h2 id="v-vector-extension-proposal-krste-asanovic:030fe38319964b117c9ffaf378fa511a">V Vector Extension Proposal: Krste Asanovic</h2>

<ul>
<li>The vector extension intends to scale to all reasonable design points
(low-cost microcontroller or high-performance supercomputer). Support both
implicit auto-vectorisation and explicit SPMD</li>
<li>Fit into the 32-bit encoding space, but be a base for future vector
extensions (e.g. crypto algorithms)</li>
<li>The goal is to ratify a proposal 12 months from now, at the 7th workshop</li>
<li>Cray-style vectors. &ldquo;The right way&rdquo; to exploit SIMD parallelism (as opposed
to the wrong way: GPUs or packed SIMD)</li>
<li>V has an implementation-dependent vector length, meaning the same code runs
across different hardware without recompiling</li>
<li>Each vector data register is configured with a width and type, or disabled.
There are also a configurable number of predicate registers. The maximum
vector length is a function of configuration, physical register storage, and
microarchitecture</li>
<li>There are a number of mandatory supported types. e.g. an RV32IF system must
support X8, X16, X32, F16, F32. This means that scalar and vector half
precision floating point is a requirement if you are supporting floating
point.</li>
<li>Each vector data register has a 4-bit field in a CSR (or multiple CSRs)
indicating its width, and another for its type.</li>
<li>A vcfgd CSR alias is defined to allow faster writes of common vector data
configurations.</li>
<li>Most user code would use the setvl instruction (which is actually setting a
CSR).</li>
<li>A 16-bit+32-bit vector addition is pleasingly straight forward to specify in
assembly</li>
<li>The architecture guarantees a minimum vector length of four regardless of
configuration. This means 1KB SRAM is required as a minimum</li>
<li>A polymorphic instruction encoding is used. A single signed integer ADD
opcode works on different size inputs and outputs, depending on the
configuration of its inputs.</li>
<li>There is support for vector atomics (e.g. vector fetch-and-add).</li>
<li>For vector function calls (e.g. in auto-vectorised code) you want to make
vector calls to a function library with separate vector calling convention.
The caller has to allocate registers for the callee to use. It sets the
maximum width, allowing the callee to change the vctype as needed.</li>
<li>For OpenCL/CUDA/SPMD, the configuration must be set at kernel launch to the
maximum width used anywhere in the call tree. It needs a general vector
function call capability with standard callee/caller save protocol</li>
<li>Krste argues autovectorisation is much preferable to OpenCL or CUDA.</li>
<li>Question: are you interested in smaller types (e.g. 4-bit). Answer: yes,
also interested in non-power-of-two types</li>
<li>Question about the calling convention: the vector configuration state is
assumed to be caller-saved (including the vector register file), meaning the
scalar ABI is unmodified</li>
</ul>

<h2 id="towards-thousand-core-risc-v-shared-memory-systems-quan-nguyen:030fe38319964b117c9ffaf378fa511a">Towards Thousand-Core RISC-V Shared Memory Systems: Quan Nguyen</h2>

<ul>
<li>Tardis is a new cache coherency protocol with greater scalability than
traditional directory coherence protocols.</li>
<li>Tardis enforces consistency through timestamps, using logical leases</li>
<li>It only tracks the exclusive owner of any particular cache line, requiring
only O(log N) storage. No broadcast invalidations, and timestamps aren&rsquo;t tied
to the core count. There is no need for synchronised real-time clocks</li>
<li>They are building a thousand-core prototype. Fit as many cores as possible
on a ZC706 FPGA, the connect in a 3D mesh to demonstrate at scale.</li>
<li>Want to adapt Tardis for release consistency (rather than sequential
consistency), and Quan introduces how they have started to do this by
introducing new timestamps</li>
</ul>

<h2 id="scrx-a-family-of-state-of-the-art-risc-v-synthesizable-cores-alexander-redkin:030fe38319964b117c9ffaf378fa511a">SCRx: a family of state-of-the art RISC-V synthesizable cores: Alexander Redkin</h2>

<ul>
<li>Syntacore develops and licenses energy-efficient programmable cores
implementing the RISC-V ISA</li>
<li>SCRx is the family of RISC-V implementations, now available for evaluation.
Each core can be extended and customised</li>
<li>The smallest core, SCR1 is less than 20kgates in a basic untethered
configuration.</li>
<li>SCR3 is a high-performance MCU core with up to 1.7DMIPS/MHz,
3.16CoreMark/MHz.</li>
<li>SCR4 is an MCU core with a high-performance FPU.</li>
<li>SCR5 is an efficient mid-range embedded core. Full MMU with Linux support.
1GHz+ at 28nm, and 1.5+DMIPS/MHz per core.</li>
<li>In the near term, want to support the latest privileged spec, adding trace
debug</li>
</ul>

<h2 id="enabling-hardware-software-co-design-with-risc-v-and-llvm-alex-bradbury:030fe38319964b117c9ffaf378fa511a">Enabling hardware/software co-design with RISC-V and LLVM: Alex Bradbury</h2>

<ul>
<li>I&rsquo;ll try and write something up for the blog later, but for now see my
slides
<a href="https://speakerdeck.com/asb/software-co-design-with-risc-v-and-llvm">here</a>.</li>
</ul>

<h2 id="vm-threads-an-alternative-model-for-virtual-machines-on-risc-vm-ron-minnich:030fe38319964b117c9ffaf378fa511a">VM threads: an alternative model for virtual machines on RISC-VM: Ron Minnich</h2>

<ul>
<li>Akaros is a research kernel originally from UC Berkeley.</li>
<li>One core idea is the &lsquo;multi core process&rsquo;. This can be thought of as a set
of cores assigned an entity to a program.</li>
<li>How do VMs fit into the Akaros model. A VM could be kind of a process.</li>
<li>Look back at how we start a process. With the introduction of fork(), it
became easy and clean. But its introduction was controversial.</li>
<li>Virtualisation on Linux/BSD/Unix requires a device (e.g. /dev/kvm). This
typically requires daemons who are used to interact with the device. In
Akaros, they did not want to recreate this.</li>
<li>Can we just run a virtual machine like we do a thread? Introduce
<code>vthread_create</code>. In Akaros, they have extended the thread model to include
virtual machine threads.</li>
<li>Virtual machine threads (vthreads) can run Linux 4.8 (with 12 lines of
patches) and any code that shares the host ring 3 address space.</li>
<li>Ring 3 and Ring V share and address space. Ring V is limited to 2^46 bytes,
while ring 3 is in a 2^47 byte address space.</li>
<li>VM threads are integrated tightly into the kernel.</li>
<li>On x86, Akaros pairs page table roots and page table pages. Page table pages
are 2x4k pages, with the process PTP in the lower 4K and the VM PTP in the
upper 4K. This makes it trivial to convert the two.</li>
<li>It is significantly easier to write virtual machine managers in Akaros than
with the Linux model</li>
<li>Akaros VMS are unlike any other VMs - threads can easily switch from being a
VM to being a host thread</li>
<li>Kernels also look like threads, and spinning up a core looks like CPU
hotplug, accomplished by spinning up a vthread with IP at the 64-bit entry
point.</li>
<li>There are a variety of implications and questions for RISC-V. How will
RISC-V handle nested paging? Can we avoid massive shadow state. How about
injecting interrupts without a vmexit?</li>
<li>RISC-V is a chance to enable software innovation. We shouldn&rsquo;t get locked
into &ldquo;but we&rsquo;ve always done it this way&rdquo;.</li>
</ul>

<h2 id="enabling-low-power-smartphone-like-graphical-uis-for-risc-v-socs-michael-gielda:030fe38319964b117c9ffaf378fa511a">Enabling low-power, smartphone-like graphical UIs for RISC-V SoCs: Michael Gielda</h2>

<ul>
<li>Industrial/embedded UIs mostly look bad, but also have terribly user
experience</li>
<li>For better UIs you mostly have to jump to Android or Linux - there&rsquo;s a lack
of a middle ground</li>
<li>For a previous project, produced a mobile-like GUI experience targeting an
MCU (STM32F4).</li>
<li>With the right approach and tools, embedded GUIs can be beautiful too</li>
<li>Their library was written in C++, with support for layers+formats. It has
its own font engine for kerning, anti-aliasing etc.</li>
<li>The GUI is specified in XML and has its own minimal CSS</li>
<li>Initially developed for eCos RTOS, and has an initial port for FreeRTOS. Can
also run on Linux.</li>
<li>To prototype on a Zynq, implemented &lsquo;micro blender&rsquo; for blending, filling,
scaling etc. This was written in Chisel.</li>
<li>Software-driven IP (silicon) is possible (and advisable!)</li>
</ul>

<h2 id="a-fast-instruction-set-simulator-for-risc-v-maxim-maslov:030fe38319964b117c9ffaf378fa511a">A Fast Instruction Set Simulator for RISC-V: Maxim Maslov</h2>

<ul>
<li>Esperanto is a stealth mode startup designing chips with RISC-V</li>
<li>Wanted a fast RISC-V ISA simulator capable of running large applications
with minimal slowdown</li>
<li>[Sorry folks, I had to duck out for a quick discussion - see the
<a href="https://riscv.org/wp-content/uploads/2016/11/Wed1330-Fast-ISA-Simulator-for-RISC-V-Maslov-Esperanto.pdf">slides</a>]</li>
</ul>

<h2 id="go-on-rv64g-benjamin-barenblat-and-michael-pratt:030fe38319964b117c9ffaf378fa511a">Go on RV64G: Benjamin Barenblat and Michael Pratt</h2>

<ul>
<li>Why RISC-V? Better architecture, lower power, faster processing, easier
accelerator development. RISC-V is not going away</li>
<li>The Go toolchain is complex. It has its own compiler, assembler (and
assembly language), and linker</li>
<li>Getting close, but the runtime doesn&rsquo;t quite compile. Hope to get it working
in the next few months.</li>
<li>In the mean time, relatively simple go programs will compile and run</li>
<li>It&rsquo;s been mostly good. One pain-point has been that other Go ports don&rsquo;t
target architectures with good conditional branches so had to emulate a flag
register. Another gripe is that loading 64-bit constants is a pain.</li>
<li>Within a couple of months you should be able to compile real Go programs and
have them run on RISC-V</li>
</ul>

<h2 id="a-java-virtual-machine-for-risc-v-porting-the-jikes-rvm-martin-maas:030fe38319964b117c9ffaf378fa511a">A Java Virtual Machine for RISC-V: Porting the Jikes RVM: Martin Maas</h2>

<ul>
<li>Why do a JVM port? Both to run interesting applications, and for research
(e.g. hardware support for GCed languages)</li>
<li>Porting OpenJDK/Hotspot for high performance, and the Jikes research VM for
academic work. This talk will focus on Jikes</li>
<li>Jikes is itself written in Java</li>
<li>JVMs have a large number of dependencies, so use the riscv-poky Linux
distribution generator to build a cross-compiled SDK and Linux image.</li>
<li>While developing, add assertions everywhere to fail as early as possible</li>
<li>Allowed the JIT to selectively emit instructions that dump trace output</li>
<li>Booting JikesRVM is no easy task (there a <em>lot</em> to do in order to get to
hello world)</li>
<li>The non-optimising JIT compiler is mostly feature-complete. Passes <sup>65</sup>&frasl;<sub>68</sub>
core tests. Targets RV64G</li>
</ul>

<h2 id="yopuzzle-an-open-v-development-platform-the-next-generation-elkim-roa:030fe38319964b117c9ffaf378fa511a">YoPuzzle - an Open-V development platform the next generation: Elkim Roa</h2>

<ul>
<li>&lsquo;Open source&rsquo; hardware. Raspberry Pi have sold 10 million boards, Arduino
sold 4.5 million boards (estimated). Some predictions indicate the market will
be worth over $1B within the next four years. These are based on commercial,
closed-source silicon</li>
<li>OnChip UIS have developed an open 32-bit RISC-V based microcontroller. To
test the initial silicon, used chip-on-board</li>
<li>RV32IM with a 3-stage pipeline. On TSMC 130nm GP. Die area 2.1mm x 2.1mm.</li>
<li>The Microprocessor core is 0.12mm2, max freq 200MHz, core voltage 1.2V, core
dynamic power at 100MHz is 167uW/MHz (all peripheral clocks disabled)</li>
<li>Arduino is mostly aimed at children in secondary schools. But what about
1-10 year olds?</li>
<li>The Open-V microcontroller is up on crowdsupply, trying to raise funds to
produce 70k chips. Aim to do the second tapeout in Q1 2017, and produce puzzle
boards in Q2 2018.</li>
<li>Elkim showed a neat live demo of the OnChip prototype along with a
browser-based programming environment</li>
</ul>

<h2 id="the-risc-v-community-needs-peripheral-cores-elkim-roa:030fe38319964b117c9ffaf378fa511a">The RISC-V community needs peripheral cores: Elkim Roa</h2>

<ul>
<li>It&rsquo;s good to have an open ISA, but what about the peripherals? e.g. PHYs,
bus IP, clocking circuitry, GPIO</li>
<li>Open hardware would translate into quality (Linux) drivers</li>
<li>There is no standard for GPIO. Want to have standard features (e.g.
switching speed, current drive) with a standard interface.</li>
<li>The OnChip peripherals use AMBA buses</li>
<li>Have a synthesizable CDR and PLL</li>
<li>Are working on USB 3.1 gen 2, including the analog frontend.</li>
<li>Have also been working on &lsquo;chipscope&rsquo; and offset correction</li>
<li>Also working on LPDDR3. PCS is done, working on UVM IP</li>
<li>Have a fully synthesised true-random noise generator, and working on NVRAM
on CMOS</li>
<li>Suggestion: have a common listing of recommended IP (e.g. SPI, I2C, USB PHY
etc).</li>
</ul>

<h2 id="sub-microsecond-adaptive-voltage-scaling-in-a-28nm-risc-v-socs-ben-keller:030fe38319964b117c9ffaf378fa511a">Sub-microsecond Adaptive Voltage Scaling in a 28nm RISC-V SoCs: Ben Keller</h2>

<ul>
<li>Energy efficiency is critical in mobile applications</li>
<li>Faster adaptive voltage scaling (AVS) saves more energy, especially for
bursty workloads</li>
<li>State of the art SoCs cannot achieve fine-grained AVS because they use
off-chip regulators</li>
<li>Integrate switch-cap regulators entirely on-die.</li>
<li>Need adaptive clock generation</li>
<li>The tape-out (~2 years ago) featured a version of Rocket. 16K I$, 32K D$, no
L2. It also feature a version of Hwacha</li>
<li>Use a Z-scale core for the power management unit</li>
<li>Taped out in 28nm FD-SOI. Die area 3.03mm2, with the core area 1.07mm2. 568K
standard cells</li>
<li>Achieved 41.8 DP GFLOPS/W</li>
<li>Body bias can be tuned to optimise efficiency for different workloads</li>
<li>Integrated voltage regulation provided 82-89% system efficiency with
adaptive clocking</li>
<li>Sub-microsecond adaptive voltage scaling provided up to 40% energy savings
with negligible performance loss</li>
<li>Will now talk about the Berkeley interpretation of &lsquo;agile&rsquo; hardware
development. See &ldquo;An Agile Approach to Building RISC-V Microprocessors&rdquo;, MICRO
2016.</li>
<li>&lsquo;Tape-ins&rsquo; before &lsquo;tape-outs&rsquo;. Sprint to an initial design that is
feature-incomplete but functional, put it through the tools etc and shake out
the issues with the VLSI flow. Then iteratively add features.</li>
<li>There have been 13 Berkeley RISC-V tapeouts in the last 5 years</li>
</ul>

<h2 id="reprogrammable-redundancy-for-cache-vmin-reduction-in-a-28nm-risc-v-processor-brian-zimmer:030fe38319964b117c9ffaf378fa511a">Reprogrammable Redundancy for Cache Vmin Reduction in a 28nm RISC-V Processor: Brian Zimmer</h2>

<ul>
<li>Voltage scaling is effective in reducing energy consumption, and SRAM limits
the minimum operating voltage</li>
<li>Instead of preventing errors, tolerate errors. A significant reduction in
the minimum voltage is possibly by tolerating 1000s of errors per MB of SRAM</li>
<li>There&rsquo;s been lots of work on the circuit-level for preventing errors, and at
the architectural level for tolerating errors</li>
<li>Goal for the chip is to prove that SRAM Vmin can be effectively lowered by
tolerating a reasonable number of failing bitcells</li>
<li>Built on Rocket and modified caches to add reprogrammable redundancy, ECC,
and BIST</li>
<li>Implemented three techniques: dynamic column redundancy (avoid single-bit
errors in data SRAM), line disable (avoid <code>&gt;=</code> 2 bit errors in data SRAM), and
bit bypass (avoid all errors in tag SRAM)</li>
<li>The system architecture involves three voltage domains. One for the uncore,
one for the core, and another for the L2 cache</li>
<li>Reprogrammable redundancy is fairly straight-forward to add to the L1, but
ECC is more difficult. The ECC decoding is pipelined. If an error is detected,
the operation is recycled</li>
<li>There is a 2% area overhead for the L2.</li>
<li>Fabricated prototype is TSMC 28nm HPM.</li>
<li>The proposed techniques achieve 25% average Vmin reduction (and 49% power
reduction) in the L2 for a 2% area overhead</li>
</ul>
 ]]></description></item><item><title>Fifth RISC-V Workshop: Day One</title><link>https://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-one/</link><guid>https://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-one/</guid><pubDate>Tue, 29 Nov 2016 15:10:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2016/10/5th-risc-v-workshop-agenda/">fifth RISC-V
workshop</a> is going
on today and tomorrow at the Google&rsquo;s Quad Campus in Mountain View. I&rsquo;ll be
keeping a semi-live blog of talks and announcements throughout the day.</p>

<h2 id="introduction-rick-o-connor-and-dom-rizzo:04209bd375e17aa5ec6945548b5da264">Introduction: Rick O&rsquo;Connor and Dom Rizzo</h2>

<ul>
<li>This workshop is yet again bigger than the last. 350+ attendees, 107 companies, 29 universities.</li>
<li>The next workshop will be May 9th-10 in Shanghai, China.</li>
</ul>

<h2 id="risc-v-at-uc-san-diego-michael-taylor:04209bd375e17aa5ec6945548b5da264">RISC-V at UC San Diego: Michael Taylor</h2>

<ul>
<li>Startup software stacks today look a light like an iceberg. A small amount
of &lsquo;value-add&rsquo; at the top, and a huge stack of open source underneath.</li>
<li>How do we build the equivalent for hardware, the fully open source ASIC
stack?</li>
<li>Need core IP, IO pads, standard cells, PLLs, high speed I/O, tools, BGA
packages, PCB design, firmware etc</li>
<li>basejump aims to provide a &lsquo;base class&rsquo; for cheap hardware development. It
includes a standard library of components, an open source package design, and
an open source motherboard</li>
<li><code>bsg_ip_cores</code> aims to be like C++ STL, but for SystemVerilog</li>
<li>BSG Ten is a recent design featuring 10 RISC-V cores that will be taping out
before the end of the year on a TSMC shuttle run.</li>
<li>Aim for 100% of the design will be open, including design files for the
chip, PCB, BGA package, firmware.</li>
<li>BSG Ten has its own 5-stage RV32IM pipeline</li>
<li>Also working on &lsquo;Certus&rsquo;, a 16nm TSMC design featuring Rocket cores, a
neural network accelerator, and the BSG I/O infrastructure.</li>
<li>Suggestion: RoCC interface should be wired to the toplevel of the Rocket
hierarchy</li>
<li>Suggestion: The RISC-V community should have at least yearly stable
end-to-end releases of full RISC-V stacks (Linux to Verilog)</li>
</ul>

<h2 id="updates-on-pulpino-florian-zaruba:04209bd375e17aa5ec6945548b5da264">Updates on PULPino: Florian Zaruba</h2>

<ul>
<li>Imperio is the first ASIC implementation of PULPino, done in UMC 65nm.<br />
Speed: 500MHz.</li>
<li>Area is 700kGE for the SoC and 40kGE for the core (1kGE = 1.44um2).</li>
<li>What is PULP? Parallel Ultra Low Power (platform).</li>
<li>PULPino is a much simplified version of PULP, featuring just 1 core, reduced
interconnect and simplified cache design.</li>
<li>Have hardware loops, post-incrementing loads and stores and SIMD instruction
extensions.</li>
<li>Over 20 companies and research institutes are using PULPino</li>
<li>PULPinov2 is targeted for Q12017. This features support for Verilator
simulation, IP-XACT description, new peripherals (uDMA), new streamlined event
unit, SDK, updated compiler, and improved documentation and tutorials</li>
<li>In the future, want to work on a secure PULPino capable of running SeL4</li>
<li>Working on a 10kGE or less RISC-V core. Evaluating 1 and 3-stage pipeline
designs.</li>
<li>Want to explore heterogeneous configurations, featuring FPU and
accelerators.</li>
<li>Find out more at the <a href="http://www.pulp-platform.org">PULP website</a>.</li>
</ul>

<h2 id="sifive-fe310-and-low-cost-hifive1-development-board-jack-kang:04209bd375e17aa5ec6945548b5da264">SiFive FE310 and low-cost HiFive1 development board: Jack Kang</h2>

<ul>
<li>SiFive is a fabless semiconductor company. Their business model is to build
custom SoC designs for their customers. Customers give specs and/or IP and
SiFive deliver packaged, tested chips.</li>
<li>Although a commercial company who may offer commercial licenses, they are
committed to updating the open source rocket-chip implementation.</li>
<li>RISC-V chips are here: the Freedom E310. This features an RV32IMAC core.<br />
320MHz+ on TSMC180G. 1.61DMIPS/MHz, 16K L1 I$, 16K data scratchpad, multiple
power domains (supports low power standby). Comes in a 6x6 48-pin QFN</li>
<li>Claim to be 9x more power efficient than Intel Quark and 2x more power
efficient than the ARM Cortex M0+.</li>
<li>The HiFive 1 is an Arduino compatible board for this chip. The board design
and SDK is/will be open source. It&rsquo;s now up on
<a href="https://www.crowdsupply.com/sifive/hifive1">CrowdSupply</a>. $59 will get you
one board.</li>
<li>The RTL for their implementations presented at the last RISC-V workshop are
now open source and <a href="https://github.com/sifive/freedom">up at GitHub</a>.</li>
<li>Question: how much (ballpark) might it cost to get 100 prototype chips? For
Freedom Everywhere (microcontroller), looking at less than $100k depending on
the level of customisation needed.</li>
<li>Question: what is the plan for getting the SiFive chips to be competitive
with the Cortex-M4 and other designs from ARM? Answer: this will come in time
with custom instructions, custom accelerators etc. The ability to customise
will result in better performance/watt than any off the shelf solution.</li>
</ul>

<h2 id="rapid-silicon-prototyping-and-production-for-risc-v-socs-neil-hand:04209bd375e17aa5ec6945548b5da264">Rapid silicon prototyping and production for RISC-V SoCs: Neil Hand</h2>

<ul>
<li>Need to support rapid evolution of IoT designs.</li>
<li>IoT class designs can be achieved in tens of k$.</li>
<li>All standards based, but not open source</li>
<li>A standard cell ASIC is typically 52-78 weeks, compared to 10 weeks for a
Baysand Metal configurable standard cell.</li>
<li>Codasip have 3-stage and 5-stage implementations RISC-V implementations. The
slide compares gate count and frequency vs Rocket and ZScale (watch out for
the slides to be posted, I didn&rsquo;t get a chance to jot down the numbers)</li>
<li>Have a story for easy extensibility, adding new instructions and having a
new SDK etc generated.</li>
<li>UltraSoC provides debug</li>
<li>LLVM is the glue that holds the solution together. They generate an LLVM
compiler based on their processor model and any customer-defined extensions.</li>
<li>A test chip will be taping out very soon. Also exploring general
availability for a dev-board</li>
<li>They are developing their own alternative to QEMU for their customers with a
non-copyleft license.</li>
</ul>

<h2 id="extending-risc-v-for-application-specific-requirements-steve-cox:04209bd375e17aa5ec6945548b5da264">Extending RISC-V for application-specific requirements: Steve Cox</h2>

<ul>
<li>Sometimes a pre-defined ISA is insufficient. May require an
application-optimised ISA. e.g. the Google TPU</li>
<li>ASIP designer is a tool for automating ASIP design. The process can start
with a pre-existing example model, e..g RISC-V</li>
<li>ASIP designer has been used in more than 250 unique SoC products</li>
<li>The speaker gives an example of a header compression accelerator. Start with
a simple 3-stage RV32IM core. This is 24.5k gates on TSMC 28HPM at 500MHz and
32GPRs.</li>
<li>First, consider instruction level parallelism. e.g. switching to a 2-slot
VLIW. This reduced cycle could by 21% and increased gate count by 31%.</li>
<li>Next, try adding application-specific instructions. This reduced the code
size by 56%, cycle count by 67%, and added 9% to the gate count (compared to
the original baseline).</li>
<li>Next, try adding a compare immediate and branch instruction. This reduces
code size by 8% and cycle count by 18% vs the previous result.</li>
</ul>

<h2 id="a-memory-model-for-risc-v-muralidaran-vijayaraghavan:04209bd375e17aa5ec6945548b5da264">A memory model for RISC-V: Muralidaran Vijayaraghavan</h2>

<ul>
<li>Why not SC/TSO? Simple implementations have low performance.</li>
<li>Why not the POWER/ARM models? Expose too many microarchitectural details and
their axiomatic models are too complex</li>
<li>Why not RMO? The dependency requirements are too strict</li>
<li>Want a simple specification with the inclusion of sufficient fences to force
sequential consistency behaviour when necessary</li>
<li>Which is why they&rsquo;ve introduced WMM: which has a simple operational
specification like SC, TSO.</li>
<li>WMM introduces the conceptual device of an invalidation buffer. This holds
stale values that may be read by a future load.</li>
<li>WMM has reconcile fences (clears the invalidation buffer) and commit fences
(flushes the store buffer).</li>
<li>All instructions are committed in order, so stores cannot overtake loads.
This prevents &lsquo;out of thin air&rsquo; generation of values</li>
<li>A write -back coherent cache hierarchy is typically global store atomic. SMT
cores with L1 write-through caches aren&rsquo;t, so don&rsquo;t do it.</li>
<li>Mapping C++11 atomic operations to WMM is straight forward</li>
<li>Question: what is the difference to the programmer vs TSO? Answer: you would
have to put a reconcile fence whenever you require load/load ordering</li>
</ul>

<h2 id="a-memory-consistency-model-for-risc-v-caroline-trippel:04209bd375e17aa5ec6945548b5da264">A Memory Consistency Model for RISC-V: Caroline Trippel</h2>

<ul>
<li>Princeton have been working on memory consistency model verification. This
resulted in PipeCheck and CCICheck. Then implemented ArMOR, which worked to
more precisely define memory models. COATCheck looks at how e.g. instructions
that are executed as a result of page table walks interact with the memory
model. Finally, TriCheck helps to verify the lowering of e.g. C++11 atomic
constructs to the ISA level, as well as checking the ISA memory model and
hardware memory model.</li>
<li>Have identified and characterised flaws in the current RISC-V memory model
specification (ASPLOS&rsquo;17).</li>
<li>Two broad categories of memory model relaxation. Preserved program order
(defines program orderings that hardware must preserve by default) and store
atomicity (defines the order in which stores become visible to cores).</li>
<li>Propose tighter preserved program order and non-multi-copy store atomicity.</li>
<li>Why allow non-multiple-copy atomic stores? Commercial ISAs e.g. ARM, Power
allow this, and RISC-V is intended to be integrated with other vendor ISAs on
a shared memory system.</li>
<li>Want preserved program order to require same address read-read ordering</li>
<li>Want PPO to maintain order between dependent instructions</li>
<li>TriCheck compares high level language outcomes to ISA-level outcomes for a
spectrum of legal ISA microarchitectures</li>
<li>The currently document RISC-V memory model lacks cumulative fences, which
are needed for C/C++ acquire/release synchronisation</li>
<li>They have formulated an english language diff of the current spec with
proposed changes, but are also working on a formal model.</li>
</ul>

<h2 id="trust-transparency-and-simplicity-eric-grosse:04209bd375e17aa5ec6945548b5da264">Trust, transparency and simplicity: Eric Grosse</h2>

<ul>
<li>Know your adversary. Many of them might sometimes be your partner as well as
your adversary (e.g. state actors). Notably, seems to be fairly little in the
way of advanced corporate espionage from other companies.</li>
<li>Fix 1: secure communications. SSL, PGP etc</li>
<li>Fix 2: authentication. e.g. two-step authentication, hardware security
devices</li>
<li>Fix 3: stay up to date with patches</li>
<li>The disclosure process in the hardware community is dramatically different
than software. e.g. rowhammer was known to some hardware vendors well before
the public disclosure.</li>
<li>Long standing practitioners&rsquo; wisdom: &ldquo;Complexity is the enemy of security&rdquo;</li>
<li>Modern systems aren&rsquo;t just incredibly complex, they&rsquo;re also largely
undocumented.</li>
<li>A paranoid&rsquo;s choice of CPU? x86 with Qubes-OS on a NUC kit. Or Coreboot,
u-root on Asus KGPE-D16 motherboard</li>
<li>For RISC-V, you have the critical advantage of openness - be sure to keep
it. Please resist adding features lightly, or else consider removing others in
compensation. Also consider a CHERI security extension, or tagged memory</li>
</ul>

<h2 id="risc-v-foundation-update-rick-o-connor:04209bd375e17aa5ec6945548b5da264">RISC-V Foundation update: Rick O&rsquo;Connor</h2>

<ul>
<li>Rick gives another overview of the RISC-V Foundation, and reiterates that
RISC-V is not an open source processor core but an open ISA specification. The
Foundation will encourage both open source and proprietary implementations</li>
<li>Every year at least two RISC-V Foundation board seats will be up for
election.</li>
<li>It&rsquo;s likely the end of year workshop each year will be in Silicon Valley,
and the Spring/Summer workshop will move locations around the year</li>
<li>The board of directors was formed in Q2 2016, and the technical and
marketing committees were formed in Q3 2016.</li>
</ul>

<h2 id="risc-v-marketing-committee-update-arun-thomas:04209bd375e17aa5ec6945548b5da264">RISC-V Marketing Committee update: Arun Thomas</h2>

<ul>
<li>The marketing committee mission: grow RISC-V mindshare and grow the RISC-V
community</li>
<li>Activities include organising RISC-V workshops and tutorials, and RISC-V
participation at industry events</li>
<li>Want to help create RISC-V educational materials for industry practitioners,
researchers, and university students</li>
<li>The marketing committee has several task groups: RISC-V workshops, outreach,
RISC-V content (creating riscv.org content and educational and marketing
materials), and member content (promoting content from RISC-V Foundation
members)</li>
<li>David Patterson announces both of his textbooks will have RISC-V editions</li>
</ul>

<h2 id="risc-v-technical-committee-update-yunsup-lee:04209bd375e17aa5ec6945548b5da264">RISC-V Technical Committee update: Yunsup Lee</h2>

<ul>
<li>Immediate goals:

<ul>
<li>Maintain a roadmap of the RISC-V ISA</li>
<li>Provide and maintain a golden simulator for the RISC-V ISA</li>
<li>Provide and maintain a set of verification/validation tests to ensure
conformance</li>
<li>To upstream software development tools (compiler, debugger etc)</li>
<li>To maintain and update a list of hardware implementations of the
architecture</li>
</ul></li>
<li>Longer term goals

<ul>
<li>Establish processes to define and standardise future ISA extensions</li>
<li>Provide guidelines for platform integration</li>
<li>Set up program committees for future RISC-V workshops</li>
</ul></li>
<li>Task groups: opcode space management, privileged ISA specification, formal
specification, debug specification, security, vector extensions, software
toolchain</li>
<li>By Feb, debug spec will be ratified by the foundation, calling convention
fixed and documented, ELF format fixed and documented, priv-1.10.0</li>
<li>By November, ratify vector extension</li>
<li>Formal specification task group: Formal models written in L3, BSV and in Coq</li>
</ul>

<h2 id="free-chips-project-yunsup-lee:04209bd375e17aa5ec6945548b5da264">Free Chips Project: Yunsup Lee</h2>

<ul>
<li>A plan to launch a not-for-profit for hosting open-source RISC-V
implementations, tools, and code</li>
<li>SiFive loves open source, believes it is essential to their mission.</li>
<li>The rocket-chip generator has had almost 4000 commits. 40% of all commits so
far come from SiFive</li>
<li>SiFive contributions to the rocket-chip repository are made under the Apache
v2 license.</li>
<li>SiFive added RV32I+M/A/F support, compressed support, blocking data cache,
and data SRAM options</li>
<li>SiFive will publish a TileLink specification</li>
<li>SiFive recently implemented a library &lsquo;Diplomacy&rsquo; for parameter negotiation.
Also added multi-clock support, clock crossings, and asynchronous reset flops</li>
<li>The SiFive blocks repository contains low-speed peripherals like SPI, UART,
PWM, GPIO, PMU. These are written in Chisel with TileLink interfaces. It also
includes wrappers for high-speed Xilinx FPGA peripherals</li>
<li>The SiFive Freedom repository has submodules for rocket-chip and
sifive-blocks and top-level SoC integration glue code</li>
<li>The Free Chips project has a mission to be a home for open-source codebases
to enable faster, better, cheaper chips. It will sustain and evolve
open-source software tools and HDL code for SoC design. It will ensure free
and open contributions are available to all of the SoC design community. It
will manage publicly accessible, online repositories of source code,
documentation and issues</li>
</ul>

<h2 id="128-bit-addressing-in-risc-v-and-security-steve-wallach:04209bd375e17aa5ec6945548b5da264">128-bit addressing in RISC-V and security: Steve Wallach</h2>

<ul>
<li>Aim for programming generality. Might have to recompile, but don&rsquo;t want to
have to restructure your software.</li>
<li>Computer virtual addresses span to local disk only, while other identifiers
such as MACs, URLs, IPv6 are globally unique. What if one unified name
structure could be developed?</li>
<li>RV128I strawman. 64-bits are used for an object ID, and the other 64 bits
used for a byte offset.</li>
<li>The object ID is a software or hardware structure considered to be worthy of
a distinct name</li>
<li>Protection and memory management are independent</li>
<li>The machine that is simplest to program wins. User cycles are more important
than CPU cycles</li>
</ul>

<h2 id="the-challenges-of-securing-and-authenticating-embedded-devices-derek-atkins:04209bd375e17aa5ec6945548b5da264">The challenges of securing and authenticating embedded devices: Derek Atkins</h2>

<ul>
<li>Why not just use symmetric encryption e.g. AES to secure your devices? It&rsquo;s
hard to deploy and it doesn&rsquo;t scale (either have one key for many devices or a
database of a huge number of keys)</li>
<li>Why do people think public key won&rsquo;t work? They think it&rsquo;s too big, too
slow, or too power hungry.</li>
<li>Many of these beliefs are true, e.g. ECC execution time on Cortex-M ARM
cores is 233-1089ms. Implementations range in 8-30KB of ROM and require
800-3000B of RAM. Hardware implementations are faster, but take a lot of
gates. RSA and Diffie-Hellman are larger and take longer</li>
<li>Fundamentally these overheads are there because a large number of 4086 bit
numbers are multiplied</li>
<li>Group theoretic cryptography (GTC) offers a potential answer. Complexity
scales linearly with security instead of quadratically like RSA, ECC etc</li>
<li>GTC can work with just 6-8 bit math</li>
<li>The Ironwood Key Agreement Protocol enables two endpoints to generated a
shared secret over an open channel. The Walnut digital signature algorithm
allows one device to generate a document that is verified by another.</li>
<li>When comparing WalnutDSA on a Rocket core, it compared very favourable to
microECC. 4.9ms run-time vs 2110ms (458ms with multiply/divide).</li>
<li>WaltnutDSA written in RISC-V assembly achieved a 3.0ms run time</li>
<li>The C implementation currently runs faster on the ARM Cortex-M3</li>
</ul>

<h2 id="risc-v-with-sanctum-enclaves-ilia-lebedev:04209bd375e17aa5ec6945548b5da264">RISC-V with Sanctum Enclaves: Ilia Lebedev</h2>

<ul>
<li>Today privilege implies trust (e.g. a hypervisor is privileged and so must
be trusted). Sanctum decouples hardware protection from trust</li>
<li>Sanctum uses hardware-assisted isolation, offering strong privacy and
integrity with low overhead</li>
<li>In remote software attestation, a trusted remote piece of hardware might
measure (hash) and sign the software that is running. The remote user can then
decides where to trust the certificate or not. Claim that prior work included
too much software in their attestation</li>
<li>Intel recently introduced SGX, which allowed a process to be placed in an
enclave. It aims to protect privacy and integrity of an enclave against a
privileged software adversary. It also protects against some physical attacks,
or instance by encrypting DRAM contents</li>
<li>There have been a number of side channel attacks demonstrated against SGX.<br />
e.g. dirty bits on page tables, or cache timing attacks</li>
<li>Sanctum aims to protect against indirect tacks (such as cache timing
attacks) as well as the direct attacks covered by SGX. It does not protect
against physical access or fault injection</li>
<li>With Sanctum, the device manufacturer acts as a certificate authority</li>
<li>Sanctum has a small software TCB, a ~5KLoC machine-mode security monitor</li>
<li>The reference Sanctum implementation was built on the Rocket RISC-V
implementation</li>
<li>Enclaves execute on private cores. i.e. it will never share L1 caches,
register, branch target buffer, TLB</li>
<li>Sanctum also isolates physical memory. DRAM regions are defined, which are
non-overlapping regions of memory assigned to certain enclaves</li>
<li>To isolate enclaves in the last level cache, allocate exclusively at a
region granularity (see the slides and/or the Sanctum paper for a description
of exactly how this works)</li>
<li>To provide hardware-assisted isolation, always maintain the invariant that
entries in the TLB are safe and necessary invariants were checked while
performing the page walk</li>
<li>Very small hardware overhead (50 gates for LLC address rotation, 600 gates
for DMA whitelist). Roughly 2% area increase in total. Roughly 6% performance
overhead in measurements</li>
</ul>

<h2 id="joined-up-debugging-and-analysis-in-the-risc-v-world-gajinder-panesar:04209bd375e17aa5ec6945548b5da264">Joined up debugging and analysis in the RISC-V world: Gajinder Panesar</h2>

<ul>
<li>Need a vendor-neutral debug infrastructure, enabling access to different
proprietary debug schemes used today by various cores</li>
<li>Need monitors into interconnects, interfaces, and custom logic which are
run-time configurable with support for cross-triggering</li>
<li>UltraSoC provides silicon IP and tools for on-chip debug</li>
<li>As an example, consider a software-defined radio chip. Might want to track
CPU cycles spent on compute vs cache stalls. Or you might track utilised DDR
bandwidth over time.</li>
<li>UltraSoC monitors are non-intrusive by default</li>
<li>Has a portfolio of 30 modules. e.g. bus monitors, communications</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>Generating a Gantt chart from HJSON input</title><link>https://www.lowrisc.org/blog/2016/10/generating-a-gantt-chart-from-hjson-input/</link><guid>https://www.lowrisc.org/blog/2016/10/generating-a-gantt-chart-from-hjson-input/</guid><pubDate>Sat, 15 Oct 2016 10:00:00 +0100</pubDate><author>info@lowrisc.org (Alex Bradbury)</author><description><![CDATA[ <p>This blog post is a slight departure from the normal topics here. Worry not,
we&rsquo;ll return to discussing Verilog, Chisel, and low-level software work soon.
I wrote a quick script to help serve a need (producing a Gantt chart) and
thought perhaps others would find it useful.</p>

<p>There are a wide range of online services to help produce and maintain Gantt
charts, but none quite offered what I was looking for. I want something open
source, easy to use, and where the underlying data is human readable and can
be version controlled. The
<a href="http://xael.org/pages/python-gantt-en.html">python-gantt</a> library formed an
excellent starting point for generating a Gantt chart in SVG, but I thought it
was worth trying to support a slightly less verbose input format.</p>

<p>Enter <a href="http://hjson.org/">hjson</a>, which aims to be a superset of json with
much more forgiving syntax. This has its disadvantages, but it does seem to
work well as a concise and easy to edit data format. A quick python script to
parse an hjson input to produce a Gantt chart and we&rsquo;re away. One feature I do
like is the use of <a href="https://github.com/amjith/fuzzyfinder">fuzzy matching</a> for
project references and dependencies. Again, this makes it easy to hack on by
hand. In the example below, I&rsquo;m able to use &ldquo;mftr widgets&rdquo; to refer to the
&ldquo;Manufacture widgets&rdquo; task.</p>

<p>Example input:</p>

<pre><code>    {
        projects: [
            {
                name: Project Alpha
                color: green
            }
        ]

        tasks: [
            {
                name: Design widget
                begin: 2016-10-14
                duration: 7,
                people: Farquaad
                project: alpha
            }
            {
                name: Set up widget production line
                begin: 2016-10-19
                duration: 6
                people: Zack
                project: alpha
            }
            {
                name: Manufacture widgets
                duration: 7
                people: Carrie
                deps: [&quot;design widget&quot;, &quot;widget prod line&quot;]
                project: alpha
            }
        ]

        milestones: [
            {
                name: Widgets start shipping
                start: 2016-10-30
                deps: [&quot;mftr widgets&quot;]
                project: alpha
            }
        ]
    }
</code></pre>

<p>Example output (<code>./hjson_to_gantt --begin-date 2016-10-10 --end-date 2016-11-13 example.hjson --name example</code>):</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2016/10/generating-a-gantt-chart-from-hjson-input/gantt_example_weekly_hu057eb1bfce3147217ea2f80a1940b12e_32473_900x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2016/10/generating-a-gantt-chart-from-hjson-input/gantt_example_weekly_hu057eb1bfce3147217ea2f80a1940b12e_32473_1800x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2016/10/generating-a-gantt-chart-from-hjson-input/gantt_example_weekly_hu057eb1bfce3147217ea2f80a1940b12e_32473_900x0_resize_box_2.png"alt='Example Gantt chart' title='Example Gantt chart' class=''
  >





<p><a href="https://github.com/lowRISC/hjson_to_gantt">hjson_to_gantt is available on Github</a>.</p>
 ]]></description></item><item><title>lowRISC&#43;IMC internship: second update</title><link>https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/</link><guid>https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/</guid><pubDate>Wed, 27 Jul 2016 14:23:34 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p><em>This is the second update from our team of interns, comprised of four
University of Cambridge undergrads. Their work is kindly sponsored by <a href="http://www.imc.nl/">IMC
Financial Markets</a> who are also helping to advise this
summer project.</em></p>

<p>At the time of our <a href="https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/">last blog post</a>, we had just finished VGA and
were working on implementing the frame buffer. Over the last 2 weeks, we have
made significant progress, completing the frame buffer and starting video decode.</p>

<p>The frame buffer was developed iteratively. Initially, it was a small Block RAM
attached to the SoC&rsquo;s AXI-Lite bus. This was useful for creating a prototype,
but its limited size lead to it being replaced with an in-memory frame buffer,
supplemented with a BRAM line buffer. The end result is shown below, the
component is connected to the TileLink bus.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/imc_2ndupd_framebuffer_hu242dcfbcd62d5e4fc74614622ef16f28_42322_300x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/imc_2ndupd_framebuffer_hu242dcfbcd62d5e4fc74614622ef16f28_42322_600x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/imc_2ndupd_framebuffer_hu242dcfbcd62d5e4fc74614622ef16f28_42322_300x0_resize_box_2.png"alt='Framebuffer diagram' title='Framebuffer diagram' class='m-2 d-block mx-auto '
  >





<p>This component builds on the VGA controller, for which documentation will be
added shortly. We have added a data mover (a unidirectional DMA), to move data
from the in memory frame buffer into the local video memory. The video memory
acts as a line buffer, the data mover (DM) moves one line from the in-memory frame
buffer at a time. Meanwhile the VGA controller flushes the new lines to the
screen, displaying the image from memory.  The DM obeys the state machine shown
in the diagram below. The DM Controller is memory mapped, allowing the CPU to
communicate with it. Currently, it can only accept one request at a time,
further requests are ignored until the component moves back to the IDLE step.
Requests consist of source and destination addresses, and a length. A planned
extension is adding a FIFO queue to the controller to allow multiple requests
to be supported.</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/imc_2ndupd_dm_states_hu497ba94ea07cdf1246499c8cae046845_21549_400x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/imc_2ndupd_dm_states_hu497ba94ea07cdf1246499c8cae046845_21549_800x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2016/07/lowriscimc-internship-second-update/imc_2ndupd_dm_states_hu497ba94ea07cdf1246499c8cae046845_21549_400x0_resize_box_2.png"alt='Data mover state diagram' title='Data mover state diagram' class='m-2 d-block mx-auto '
  >





<p>The decision was made to implement a unidirectional data mover over a more
complex and capable bidirectional DMA component as only unidirectional movement
was needed for now. Later on, we will need bidirectional access as the
video accelerator will need to write back to memory. We hope to enable
bidirectionality by simply duplicating the existing unidirectional design.</p>

<p>Our next tasks relate to video decoding. We will be adapting a reference
MPEG-2 codec to decode video on the FPGA and adding extra components to the
SoC design to improve the performance of the codec, such as DCT and iDCT
accelerators.</p>
 ]]></description></item><item><title>Notes from the fourth RISC-V workshop</title><link>https://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/</link><guid>https://www.lowrisc.org/blog/2016/07/notes-from-the-fourth-risc-v-workshop/</guid><pubDate>Thu, 14 Jul 2016 16:08:07 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>Many of the lowRISC team (Robert Mullins, Wei Song, and Alex Bradbury) have
been in Boston this week for the fourth RISC-V workshop. By any measure, this
has been a massive success with over 250 attendees representing 63 companies
and 42 Universities. Wei presented our most recent work on integrating trace
debug, which you&rsquo;ll soon be able to read much more about here (it&rsquo;s worth
signing up to our <a href="https://www.lowrisc.org/about/">announcement list</a> if you want to
be informed of each of our releases).</p>

<h2 id="risc-v-foundation-update-rick-o-connor:87aa58e6b61ee0a40afd76694b4dc9af">RISC-V Foundation update: Rick O&rsquo;Connor</h2>

<ul>
<li>Next RISC-V Workshop will be Nov 29th-30th at Google&rsquo;s Mountain View, CA</li>
<li>The RISC-V ISA and related standards shall remain open and license-free to
all parties, and the member agreement with RISC-V Foundation will include a
license for the trademark</li>
<li>Trademark license for commercial use is part of being a silver, gold, or
platinum member</li>
<li>Founding member status has now finished.</li>
<li>You don&rsquo;t have to be a member to participate in specifications - each task
group must include at least one round of public consultation.</li>
<li>Question: any plans for workshops outside of the USA? Answer: yes, we would
like to do that</li>
</ul>

<h2 id="risc-v-interrupts-krste-asanović:87aa58e6b61ee0a40afd76694b4dc9af">RISC-V interrupts: Krste Asanović</h2>

<ul>
<li>Want a standard that is useful in high performance Unix-like systems (fast
cores, smart devices), low/mid embedded systems (slow cores, dumb devices),
and high-performance realtime systems (can&rsquo;t waste time on interrupt overhead)</li>
<li>Design goals: simplicity, support all kinds of platforms, allow tradeoffs
between performance and implementation cost, be flexible to support
specialised needs</li>
<li>Interrupts are either local or global.

<ul>
<li>Local interrupts are directly connected to one hardware thread (hart) with
no arbitration. On RISC-V, there is currently only two of these: software
and timer.</li>
<li>For global (external) interrupts, they are routed via the memory-mapped
Platform-Level Interrupt Controller (PLIC)</li>
</ul></li>
<li>A new CSR, the Machine Interrupt Pending (mip) register is added. It has
separate interrupts for each supported privilege level.</li>
<li>User-level interrupt handling is an optional feature. This may be used in
secure embedded systems.</li>
<li>Software interrupts

<ul>
<li>MSIP (machine software interrupt) can only be written in machine mode via
a memory-mapped control register. This is used for inter-hart interrupts.
Also have HSIP, SSIP, USIP. A hart can only write its own HSIP, SSIP, USIP.</li>
<li>The App/OS/Hypervisor can only perform inter-hart interrupts via
ABI/SBI/HBI calls</li>
</ul></li>
<li>Timer interrupts: MTIP is a single 64-bit real-time hardware timer and
comparator in M-mode. You want this because due to frequency scaling etc, just
going by cycle count is not useful. HTIP, STIP, UTIP are set up by M-mode
software.</li>
<li>When running at a given privilege level, all interrupts for lower levels are
disabled.</li>
<li>All interrupts trap to M-mode by default, and M-mode software can redirect
to the other privilege level as necessary. mideleg can be used to
automatically delegate interrupts to the next privilege level.</li>
<li>Conceptually, when interrupts come in to the PLIC they are handled by the
gateway. This abstracts away differences between different interrupt sources.
e.g. level-triggered, edge-triggered etc. A new request isn&rsquo;t forwarded to the
PLIC core unless the previous request&rsquo;s handler has signaled completion.</li>
<li>Each interrupt has an ID and priority. These priorities can be fixed or
variable. The PLIC stores per-target information</li>
<li>An interrupted hart will try to claim an interrupt from the PLIC with a read
of the memory-mapped register. It could have been claimed by someone else, and
the PLIC core is responsible for ensuring the interrupts it received by only
one hart.</li>
<li>If you want to add more levels of nested interrupt handling, add more harts
to your system.</li>
<li>The position of the PLIC in the memory map isn&rsquo;t defined by the
specification because many people will have existing memory maps.</li>
<li>Question: would you have multiple PLICs on a multi-core system? Answer:
conceptually, there is only one PLIC though it could be implemented in a
distributed fashion.</li>
</ul>

<h2 id="formal-specification-of-risc-v-uniprocessor-consistency-arvind:87aa58e6b61ee0a40afd76694b4dc9af">Formal specification of RISC-V uniprocessor consistency: Arvind</h2>

<ul>
<li>Joint project with Adam Chlipala. The slogan is &ldquo;chips with proofs&rdquo;. These
are multicore chips that satisfy the RISC-V ISA specifications and are capable
of booting Linux.</li>
<li>Both the design and the proofs must be modular and amenable to modular
refinement.</li>
<li>Mostly concerned about microarchitecture and memory system correctness.</li>
<li>Specs and designs are expressed in Bluespec.</li>
<li>See also <a href="http://plv.csail.mit.edu/kami/">Kami</a>, a framework for Coq for
performing proofs about Bluespec programs.</li>
<li>A specification should avoid using concepts such as partially executed
instructions or &ldquo;a store was been performed with respect to&hellip;&rdquo;.
Non-determinism is necessary, but unspecified behaviour should be avoided.</li>
<li>Semantics are defined in terms of &lsquo;I2E&rsquo;, the Instantaneous Instruction
Execution framework. Simply, an instruction executes instantaneously ensuring
the processor state is always up to date. Data moves between processors and
memory asynchronously according to some background rules. Memory
model-specific buffers are placed between the processor state and memory.</li>
<li>WMM is a possible memory model for RISC-V, where both loads and stores can
be re-ordered. Conceptually, invalidation buffers are added alongside the
store buffer in order to make stale values visible. Whenever a stale value is
removed from the invalidation buffer, any values that are older (more stale)
must also be removed.</li>
<li>Memory issues arise even within a uniprocessor, due to self-modifying code
and page table access and the TLB. The fundamental issue is with multiple
paths to the same memory.</li>
<li>Arvind is concerned that when defining formal semantics, a very weak memory
model may become very (too?) complex.</li>
</ul>

<h2 id="heterogeneous-multicore-risc-v-processors-in-fd-soi-silicon-thomas-peyret:87aa58e6b61ee0a40afd76694b4dc9af">Heterogeneous Multicore RISC-V Processors in FD-SOI Silicon: Thomas Peyret</h2>

<ul>
<li>Want to build a large ecosystem around FD-SOI in Europe, including IP and
chipset libraries.</li>
<li>PULSAR is a RISC-V big.LITTLE-style heterogeneous multicore. Two small cores
(rocket without FPU, 8KB L1 caches) and two big cores (3-way super-scalar BOOM
and 32KB L1 caches). It features an AMBA interconnect generated by Synopsys
CoreAssembler and has multiple body-bias zones.</li>
<li>Currently looking to use it in the context of a pedestrian navigation
system.</li>
<li>128-bit link to DDR5 controller, plus 4+4GTX SERDES to a separate FPGA.</li>
<li>Also features the AntX processor, which is a very small 32-bit RISC Harvard
design from CEA Tech.</li>
<li>Used hardware emulation with ZeBu (Synopsys)</li>
<li>Also used SESAM for virtual prototyping (based on SystemC/TLM 2.0). This is
up to 90% accurate compared to RTL. Have also developed SCale, a new parallel
SystemC kernel.</li>
<li>Synthesis results show 2.64mm2, 0.6W, 700MHz.</li>
<li>Question: will the work be open-sourced? Answer: Don&rsquo;t know yet.</li>
</ul>

<h2 id="nvidia-risc-v-evaluation-story-joe-xie:87aa58e6b61ee0a40afd76694b4dc9af">NVidia RISC-V evaluation story: Joe Xie</h2>

<ul>
<li>Want to reproduce the existing NVIDIA falcon CPU with a new ISA</li>
<li>Falcon - FAst Logic CONtroller. Introduced over 10 years ago and used in
more than 15 different hardware engines today. Low area, secure, flexible. 6
stage pipeline, variable length instructions (proprietary NVIDIA ISA).</li>
<li>The next generation for Falcon is needed for higher performance and rich OS
support. Old Falcon is 0.67 DMIPS/MHz, 1.4 Coremark/Mhz</li>
<li>Options were to buy access to a current architecture (MIPS, ARM, others) or
build (move to RISC-V or improve Falcon). Obviously, they elected to move to
RISC-V. The fact the ISA is extensible is a key advantage. Want an area of
less than 0.1mm2 at 16FF.</li>
<li>NV-RISCV is 5 stage in-order issue, out-of-order execution. It has a
in-order write buffer. No FPU. Makes use of an MPU with base and bound
protection. It will initially be added to the Falcon as a 2nd core to provide
easy backwards compatibility.</li>
<li>Area for 16FF: Falcon 0.03mm2 vs Rocket 0.055mm2 vs NV-RISC-V 0.05-0.06mm2.</li>
<li>Did a lot of cache optimisations to tolerate large latency. Store buffer,
write merging, line-fill buffer, victim buffer, stream buffer.</li>
<li>Areas of interest include toolchain (for automotive, debug, performance
tuning, flexibility, ilp32/ilp64). Also security (crypto instructions and
extensions), and adding cache manipulation instructions.</li>
<li>Question: why design your own core rather than use an existing one? Answer:
after evaluating the options, it made the most sense. The motivation to go to
RISC-V was technical as well as influenced by cost.</li>
</ul>

<h2 id="isa-shootout-a-comparison-of-risc-v-arm-and-x86-chris-celio:87aa58e6b61ee0a40afd76694b4dc9af">ISA Shootout – a Comparison of RISC-V, ARM, and x86: Chris Celio</h2>

<ul>
<li>Recently released a new tech report <a href="http://arxiv.org/abs/1607.02318">The renewed case for the Reduced
Instruction Set Computer</a>.</li>
<li>The conventional wisdom is that CISC ISAs are more expressive and dense than
RISC ISAs, while RISC ISAs map well to high-performance pipelines. Of course,
a number of designs have CISC instructions translating to RISC-like micro-ops.</li>
<li>Chris&rsquo; contention is that a well designed RISC ISA can be very competitive
with CISC ISAs. It can be denser and higher performance.</li>
<li><code>ldmiaeq sp!, {r4-r7, PC}</code> is an ARMv7 instruction (load
multiple-increment-address) which will write to 7 registers and perform 6
loads. This is a common idiom for stack pop and return from a function call.</li>
<li>Goal is to get a baseline to measure the current code generation quality of
the RISC-V gcc port. Given a fixed ISA, what can the compiler do to improve
performance? What can the programmer do? What can the micro-architect do? A
specific non-goal is to lobby for more instructions (CISC or otherwise).</li>
<li>Dynamic instruction count can be very misleading due to the possibility it
decodes to many micro-ops. Conversely, macro-op fusion may take multiple
instructions and fuse them on the fly.</li>
<li>Looking at 6 ISAs, using 12 benchmarks from SpecINT 2006.</li>
<li>Average 16% more instructions for RISC-V vs x86-64, though roughly even in
terms of micro-ops. With the compressed instruction set extension, RISC-V wins
in terms of instruction bytes fetched on many of the benchmarks. Overall, 28%
fewer instruction bytes than ARMv7 and 8% fewer than x86-64.</li>
<li>Adding array indices is the most common idiom, so why not add an indexed
load instruction to match x86? But with the compressed ISA, a pair of
compressed instructions can be treated as an indexed load by the decoder.</li>
<li>Proposed macro-op fusion pairs: load effective address, indexed load, clear
upper word. These idioms provide 5.4% fewer &ldquo;effective&rdquo; instructions for RV64.</li>
<li>Fusion isn&rsquo;t just for superscalar out-of-order cores. Chris believes it
should be used by all RISC-V cores. For instance, Rocket (single issue) can be
modified to perform this.</li>
<li>Better code generation is possible if the compiler knows fusion is
available.</li>
<li>RISC can be denser, faster, and stay simple!</li>
<li>Question: will compressed become standard? Answer: it may become part of the
de-facto standard or even Linux ABI standard. Still more to be done to fully
understand the complexity for processor implementations.</li>
<li>Question: how does macro-op fusion interact with things like faults and
precise exceptions? Answer: it does add extra complexity. One solution is if
you get a fault, then re-fetch and execute without fusion.</li>
</ul>

<h2 id="trace-debugging-in-lowrisc-wei-song:87aa58e6b61ee0a40afd76694b4dc9af">Trace debugging in lowRISC: Wei Song</h2>

<ul>
<li>Watch this blog for much more on our trace debug work very soon.</li>
</ul>

<h2 id="risc-v-i-o-scale-out-architecture-for-distributed-data-analytics-mohammad-akhter:87aa58e6b61ee0a40afd76694b4dc9af">RISC-V I/O Scale Out Architecture for Distributed Data Analytics: Mohammad Akhter</h2>

<ul>
<li>For analytics, need a deep net with many nodes. This demands balanced
low-latency computing I/O, memory, and storage processing.</li>
<li>Wireless network evolution is driven by real-time data with better QoS. Very
rapid growth rate in bandwidth and reduction in round-trip time latency for
LTE, LTE-A, 5G, &hellip;</li>
<li>Built a deep learning micro-cluster. Uses RapidIO, NVidia GPUs. No RISC-V
though. They&rsquo;ve then looked at how this might look with RISC-V cores instead.</li>
<li>Want to support AXI rand RapidIO.</li>
<li>Produced a hardware simulation model with TileLink packet generators
producing data that is transferred over a RapidIO transport.</li>
<li>A RISC-V CPU generator model with port for RapidIO available (where?)</li>
</ul>

<h2 id="coherent-storage-the-brave-new-world-of-non-volatile-main-memory-dejan-vucinic:87aa58e6b61ee0a40afd76694b4dc9af">Coherent storage. The brave new world of non-volatile main memory: Dejan Vucinić</h2>

<ul>
<li>There are two emerging resistive non-volatile memories. ReRAM and PCM. Read
latency is orders of magnitude lower than NAND, somewhere between that of DRAM
and NAND.</li>
<li>Should non-volatile memories be treated like memory, or like storage?</li>
<li>For now, it seems to make sense to have the digital logic for the NVM
controller off-chip (including coherence state).</li>
<li>Wear levelling, data protection at rest further motivate the controller
being placed along with non-volatile media.</li>
<li>One potential approach is a coherent storage controller in reconfigurable
logic.</li>
<li>RISC-V shopping list: Hardware coherence, fast+wide ports for peripherals to
join the coherence domain, relinquish the non-volatile memory controller for
now, and get used to high variability in main memory response time.</li>
</ul>

<h2 id="risc-v-as-a-basis-for-asip-design-drake-smith:87aa58e6b61ee0a40afd76694b4dc9af">RISC-V as a basis for ASIP design: Drake Smith</h2>

<ul>
<li>&ldquo;Every design is different, so why is every embedded processor the same?&rdquo;</li>
<li>Using RISC-V as a basis for ASIP can avoid many concerns. SecureRF produces
quantum-resistant security for low resource devices using group theoretic
cryptography.</li>
<li>Using the Microsemi Smartfusion2+ board as the test platform.</li>
<li>With a software-only port, their WalnutDSA was 63x faster than Micro-ECC.</li>
<li>Adding a custom instruction to accelerate it only added 2% area on the FPGA
and gave another 3x increase in speed.</li>
</ul>

<h2 id="an-updated-on-building-the-risc-v-software-ecosystem-arun-thomas:87aa58e6b61ee0a40afd76694b4dc9af">An updated on building the RISC-V software ecosystem: Arun Thomas</h2>

<ul>
<li>2016 wishlist: Upstream GNU toolchain, Clang//LLVM and QEMU. Also Linux
kernel, Yocto, Gentoo, and BSD. Plus Debian/RISC-V port.</li>
<li>Now people are getting ready to send patches for review for toolchains and
QEMU.</li>
<li>FreeBSD 11 will officially support RISC-V. For the Debian/RISC-V port, see
Manuel&rsquo;s talk tomorrow.</li>
<li>Arun argues the Foundation should fund developers to build core software
infrastructure. Additionally, we should also decide on a process for proposing
ISA enhancements.</li>
<li>What might funded developers do? Upstreaming and maintainership, porting
software, performance optimisation/analysis, enhancing test suites and
methodologies, continuous integration and release management.</li>
<li>How should proposals be be handled? Various groups have approaches for this
already. e.g. Rust, Python, IEEE, IETF. Arun has put together a <a href="https://github.com/arunthomas/riscv-rfcs">straw-man
proposal on specification
development</a>.</li>
<li>Arun would like to see the next iteration for the privileged spec to go
through a comment period.</li>
</ul>

<h2 id="orca-lve-embedded-risc-v-with-lightweight-vector-extensions-guy-lemieux:87aa58e6b61ee0a40afd76694b4dc9af">ORCA-LVE, embedded RISC-V with lightweight vector extensions: Guy Lemieux</h2>

<ul>
<li>Using 900LUTs for a speedup of 12x. Proposed and added a standardised vector
engine to their processor.</li>
<li>Smallest version of the ORCA implementation can fit in 2k LUTS on the
Lattice iCE40 and runs at about 20MHz.</li>
<li>Their approach for lightweight vector extensions is to add a dedicated
vector data scratchpad and to re-use the RISC-V ALU.</li>
<li>Vector operands are just RISC-V scalar registers containing pointers into
the vector scratchpad.</li>
<li>To encode vector operations, they use two 32-bit instruction bundles.</li>
<li>To allocate vector data, just use an alternative malloc function. Intrinsics
are available to manipulate vectors.</li>
<li>In the future, want to add 2D and 3D operations as well as subword SIMD.</li>
<li>Why not using the proposed RISC-V vector extensions? Because the detailed
proposal isn&rsquo;t yet released, and LVE intends to be more lightweight and lower
overhead.</li>
<li>Question: can these instructions raise exceptions? Answer: that hasn&rsquo;t been
properly defined yet.</li>
</ul>

<h2 id="fpgarduino-a-cross-platform-risc-v-ide-for-the-masses-marko-zec:87aa58e6b61ee0a40afd76694b4dc9af">FPGArduino. A cross-platform RISC-V IDE for the masses: Marko Zec</h2>

<ul>
<li>The main attraction of the Arduino IDE is simplicity and quick results</li>
<li>Provide pre-compiled toolchains for OSX, Windows, and Linux. For C
libraries, took mainly from FreeBSD.</li>
<li>boards.txt defines IDE menu entries and options. Also support pre-build FPGA
bitstreams and support for upload from IDE.</li>
<li>Have produced f32c, a retargetable scalar RISC-V core written (mostly) in
VHDL.</li>
</ul>

<h2 id="sifive-s-risc-v-computer-jack-kang:87aa58e6b61ee0a40afd76694b4dc9af">SiFive&rsquo;s RISC-V computer: Jack Kang</h2>

<ul>
<li>SiFive is a fabless semiconductor company building customisable SoCs</li>
<li>They produce a free and open platform spec for their platforms</li>
<li>This week announced &ldquo;Freedom Unleashed&rdquo; (Linux application cores, high speed
peripherals), and &ldquo;Freedom Everywhere&rdquo; (targeted at embedded and IoT).</li>
<li>The Freedom Unleashed demo will be shown today, running on an FPGA connected
to PCIe.</li>
<li>Question: why 180nm for the Freedom Everywhere, isn&rsquo;t it rather old now?
Answer: it is low cost and fast time to market so will make sense for some.</li>
<li>Question: will peripherals etc be open sourced? Answer: things we do
ourselves e.g. SPI will be.</li>
</ul>

<h2 id="mit-s-riscy-expedition-andy-wright:87aa58e6b61ee0a40afd76694b4dc9af">MIT&rsquo;s RISCy expedition: Andy Wright</h2>

<ul>
<li>Build proofs from small components, build them up to complete, real
processors.</li>
<li>They are now releasing their work, the Riscy processor library, Riscy BSV
utility library, and reference processor implementations. Currently
multi-cycle and in-order pipelined. Soon, out-of-order execution.</li>
<li>Have infrastructure for tandem verification.</li>
<li>How is modular design possible? RTL modules are not modularly refinable
under composition, i.e. implementation details of one module may put
additional constraints on another. But BSV language features do support
composability.</li>
<li>The processor design flow involves taking the Riscy blocks, forming the
initial connections, performing modular refinement, and then scheduling
optimisation to reduce overheads due to BSV scheduling logic.</li>
<li>Connectal implements the connections from FPGA to a host computer through
PCIe. This also works on Zynq FPGAs with an AXI transport.</li>
<li>Tandem verification: run the same program on two RISC-V implementations at
once. Generated verification packets at commit stage, use non-deterministic
information from the implementation under test for synchronisation, and then
compare the results.</li>
<li>Check out the code <a href="https://github.com/csail-csg/riscy">on Github</a>.</li>
<li>Planned work involves formal specifications, proofs for modules, and proof
for processors.</li>
</ul>

<h2 id="a-software-programmable-fpga-iot-platform-andrew-canis:87aa58e6b61ee0a40afd76694b4dc9af">A software-programmable FPGA IoT platform: Andrew Canis</h2>

<ul>
<li>Lattice&rsquo;s vision for an FPGA IoT platform is that it has high ease of use
(use C/C++ as design entry), and flexibility for a range of sensors,
actuators, communication devices.</li>
<li>A hybrid computing solution: the RISC-V processor with FPGA hardware. RISC-V
processor plus LegUp-generated hardware acclerators to handle the processing
part of the IoT platform.</li>
<li>The Lattice RISC-V processor has a 4 stage pipeline, and can be configured
for RV32I, RV32IM, and RV32IC. It compares favourably to the LM32, e.g. RV32IC
takes 1.6K LUTs vs 2K LUTs for the LM32 while also achieving higher DMIPS and
code density.</li>
<li>LegUp is a high level synthesis tool.</li>
<li>For a sum of squares of speech samples example, the LegUp synthesized
accelerator gives a 5.4x speedup vs the RISC-V software implementation.</li>
<li>LegUp has plans to support LegUp-synthesized custom instruction
implementations</li>
</ul>

<h2 id="apache-mynewt-james-pace:87aa58e6b61ee0a40afd76694b4dc9af">Apache mynewt: James Pace</h2>

<ul>
<li><a href="http://mynewt.apache.org">Mynewt</a> is an open source OS for constrained IOT.
Supports ARM, AVR, Mips (and now RISC-V?).</li>
<li>Apache Mynewt is &ldquo;Linux&rdquo; for devices that cannot run Linux.</li>
<li>It is a community effort, run through the Apache Software Foundation.
Currently ~280k lines of code.</li>
<li>Plans for Bluetooth 5 support in the future, deployments for industrial
wireless sensor networks.</li>
<li>The Mynewt kernel is a pre-emptive, multi-tasking RTOS with a tickless
kernel.</li>
<li>Question: does Mynewt support SMP? Answer: not currently.</li>
</ul>

<h2 id="dsp-isa-extensions-for-an-open-source-risc-v-implementation-pulp-pasquale-davide-schiavone:87aa58e6b61ee0a40afd76694b4dc9af">DSP ISA extensions for an open-source RISC-V implementation (PULP): Pasquale Davide Schiavone</h2>

<ul>
<li>RI5CYv2 is an evolution of their RISC-V implementation. It is an RV32IMC
implementation with some PULP-specific ISA extensions to target energy
efficiency.</li>
<li>Includes support for profiling and core execution trace.</li>
<li>Coremark/Mhz is competitive with the ARM Cortex M4.</li>
<li>Hardware loop instructions benefit control-intensive applications</li>
<li>Add DSP extensions to improve energy efficiency for signal processing
algorithms. Want to execute more quickly so the core can enter a low-power
mode.</li>
<li>RI5CYv2 adds dot product between vectors, saturation instructions, small
vector instructions, &hellip; GCC support is present for these.</li>
<li>These additional instructions give a performance increase of up to 9.5x,
6.4x on average for data-intensive kernels.</li>
<li>The fan-out 4 of the critical path is 31. When laying out at 65nm, area is
67 kilo-gate equivalents.</li>
<li>Released so far just 10% of what they will release in the future, so there&rsquo;s
much more to come. The full PULP will be released in December, an in the
meantime you can use the PULPino core.</li>
</ul>

<h2 id="the-dover-edge-a-metadata-enhanced-risc-v-architecture-andré-dehon:87aa58e6b61ee0a40afd76694b4dc9af">The DOVER Edge: A Metadata-Enhanced RISC-V Architecture: André DeHon</h2>

<ul>
<li>How do we handle the &lsquo;edge&rsquo; of a metadata tagged system? e.g. I/O to the
untagged world, legacy devices, DMA.</li>
<li>PUMP is a metadata processing engine that checks tags upon every instruction
and memory access.</li>
<li>For slave devices, tags can be associated with memory mapped devices. These
are used to write rules to control access. This allows giving configuration
control to particular drivers, without giving the driver control to all
devices or other privileges.</li>
<li>DMA I/O policies might target: containment (who&rsquo;s allowed to read/write a
buffer), integrity (mark incoming data as untrusted), secrecy, and
data presence/synchronisation.</li>
<li>Add new supported opcodes as input to the PUMP representing DMA load and DMA
store. Modify PC tag and Instr tag to represent the state of the DMA and the
DMA source.</li>
<li>If a DMA is deemed to be misbehaving, it can be totally disabled by the PUMP
or the particular operation could be discarded.</li>
<li>In this design, there is both an IO pump and a processor PUMP. The IO pump
is pipelined so it will not reduce system throughput.</li>
<li>The IO pump generates an interrupt on a rule miss. The miss handler uses the
same rule function as for the processor PUMP.</li>
</ul>

<h2 id="improving-the-performance-per-area-factor-of-risc-v-based-multi-core-systems-tobias-strauch:87aa58e6b61ee0a40afd76694b4dc9af">Improving the performance-per-area factor of RISC-V based multi-core systems: Tobias Strauch</h2>

<ul>
<li>The speaker has spent many years working on C-slow retiming</li>
<li>System hyper pipelining is based on C-slow retiming. It replaces original
registers with memories, and adds thread stalling and bypassing features.</li>
<li>In &lsquo;deep pipelining&rsquo;, run one thread in &lsquo;beast mode&rsquo;. Switch to another
thread if an instruction dependency is detected.</li>
<li>Created the microRISC project, working on the V-scale design. With SHP was
able to move from 80MHz to 250MHz.</li>
<li>miniRISC (based on lowRISC). Want to perform SHP on the Rocket core. The
speaker proposes that instead of having multiple minions you have a
hyper-pipelined core.</li>
<li>The source code of the projects will be released in PDVL, a new language
&ldquo;way better than Chisel and Bluespec Verilog(!)&rdquo; that produces VHDL and
Verilog.</li>
</ul>

<h2 id="working-towards-a-debian-risc-v-port-manuel-a-fernandez-montecelo:87aa58e6b61ee0a40afd76694b4dc9af">Working towards a Debian RISC-V port: Manuel A. Fernandez Montecelo</h2>

<ul>
<li>Debian is a community of volunteers who care about free and open-source
software.</li>
<li>Debian contains more than 22k source packages</li>
<li>Debian contains a mix of officially supported ports, unofficial releases (on
Debian infrastructure but not part of the stable release process), and others
are outside of Debian infrastructure (e.g. Raspbian).</li>
<li>Why a Debian port for RISC-V? Interested as Manuel feels affinity with the
goals of the project, previously enjoyed working with the OpenRISC port.</li>
<li>Goal is to have a complete, fully supported, continuously updated Debian
port. The initial step is to bootstrap a viable, basic OS disk image.</li>
<li>The chosen RISC-V target is 64-bit little endian. This is the recommended
default and what is planned for the lowRISC board.</li>
<li>Been working on and off since November 2014. Upstreaming of toolchains etc
would be very helpful. Have now built 300-400 &ldquo;essential&rdquo; packages.</li>
<li>Packages where mostly cross-compiled, with some compiled &lsquo;natively&rsquo; inside
emulators. Some require building multiple times to e.g. break circular
dependencies.</li>
<li>ABI changes mean work has to restart from scratch.</li>
</ul>

<h2 id="kami-a-framework-for-hardware-verification-murali-vijayaraghavan:87aa58e6b61ee0a40afd76694b4dc9af">Kami. A framework for hardware verification: Murali Vijayaraghavan</h2>

<ul>
<li>This work is part of the &ldquo;Riscy Expedition&rdquo; by MIT. Want to build chips with
proofs.</li>
<li>Must to able to verify an optimisation is correct independent of contexts,
to enable modular verification of a full system.</li>
<li>Kami is a DSL inside the Coq proof assistant for verifying Bluespec-style
hardware.</li>
<li>Have finished building required theory and proof automation infrastructure.<br />
Are currently working on proving a cluster of multi-cycle cores connected to a
coherent cache hierarchy implements sequential consistency.</li>
</ul>
 ]]></description></item><item><title>lowRISC / IMC internship week one - VGA output</title><link>https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/</link><guid>https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/</guid><pubDate>Thu, 07 Jul 2016 14:23:34 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p><em>Begnning on Monday, June 27th, we had a team of four University of
Cambridge undergrads begin a 10 week
internship working on the lowRISC project at the Computer Laboratory,
kindly sponsored by <a href="http://www.imc.nl/">IMC Financial Markets</a> (who are also
helping to advise this project). The team will be blogging regularly over the
course of the summer - I&rsquo;ll pass over to them to introduce
themselves.</em></p>

<p>After some initial brainstorming, we decided to aim to extend the
current lowRISC SoC design to enable video output, with the final goal of
playing video smoothly at a resolution of 640x480 on FPGA. The photo below
shows the four of us (left to right: Gary Guo, Profir-Petru Pârțachi, Alistair Fisher,
Nathanael Davison).</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/imc_lowrisc_interns_potatocam_hu8611ede73a0d62f7c7bd44ddfb81916d_102994_450x0_resize_q75_box.jpg 1x, https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/imc_lowrisc_interns_potatocam_hu8611ede73a0d62f7c7bd44ddfb81916d_102994_900x0_resize_q75_box.jpg 2x '
    src="https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/imc_lowrisc_interns_potatocam_hu8611ede73a0d62f7c7bd44ddfb81916d_102994_450x0_resize_q75_box.jpg"alt='2016 lowRISC/IMC internship team' title='2016 lowRISC/IMC internship team' class='m-2 d-block mx-auto '
  >





<p>The final goal has been decomposed into several milestones: adding VGA
functionality to lowRISC, adding an in-memory framebuffer, implementing a
video codec for RISC-V and designing and creating a 2D accelerator to speed
up video decoding. Our plan for the augmented SoC architecture is
shown the in the diagram below:</p>











  
  

  
  

  
  

  <img
    srcset='https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/imc_lowrisc_vga_diagram_week1_hueb5ccec2b717b1a917f1b772fb1c2aa2_110393_650x0_resize_box_2.png 1x, https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/imc_lowrisc_vga_diagram_week1_hueb5ccec2b717b1a917f1b772fb1c2aa2_110393_1300x0_resize_box_2.png 2x '
    src="https://www.lowrisc.org/blog/2016/07/lowrisc-/-imc-internship-week-one-vga-output/imc_lowrisc_vga_diagram_week1_hueb5ccec2b717b1a917f1b772fb1c2aa2_110393_650x0_resize_box_2.png"alt='Drawing' title='Drawing' class='m-2 d-block mx-auto '
  >





<p>In our first week, we&rsquo;ve succeeded in adding VGA output to lowRISC, a
demonstration of this is shown in the video below. The demo shows lowRISC
instantiated on a Nexys4 DDR board (Artix-7) displaying a static image
that has been loaded into its BRAM. This image is read from SD card by a
bare-metal program on the RISC-V application core, which then loads it in to
the memory-mapped BRAM we hooked up to the AXI-Lite bus. The on-chip BRAM
is obviously a very limited resource, so our next step is to use the
board&rsquo;s DRAM to hold the framebuffer and make use of the BRAM for a
line-buffer.</p>

<iframe width="560" height="315" src="https://www.youtube.com/embed/256wh1QOuH0" frameborder="0" allowfullscreen></iframe>

<p>We aim to publish something every week, either in the form of a blog post
like this or as a more detailed guide showing how to repeat our work. Next
week we&rsquo;ll share a guide on how to enable VGA in lowRISC. By the end
of the summer, as well as a working technical demo, we will also have
produced detailed documentation on the whole process of adding a
customised accelerator to lowRISC.</p>
 ]]></description></item><item><title>Announcing the LibreCores design contest and ORConf 2016</title><link>https://www.lowrisc.org/blog/2016/06/announcing-the-librecores-design-contest-and-orconf-2016/</link><guid>https://www.lowrisc.org/blog/2016/06/announcing-the-librecores-design-contest-and-orconf-2016/</guid><pubDate>Tue, 28 Jun 2016 15:39:34 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>Our friends and collaborators at the <a href="http://fossi-foundation.org/">Free and Open Source Silicon
Foundation</a> have launched the <a href="http://librecores.org/designcontest">LibreCores design
contest</a>. This is a student design
contest which aims to recognise and reward contributions to the open source
hardware ecosystem. The main evaluation criteria are:</p>

<ul>
<li>Openness. Your work must be published under an established Open Source
license.</li>
<li>Reusability. How easily can your work be used and modified by someone else?
Is it well documented? Do you plan to continue to work on your project and help
others to get started?</li>
<li>Usefulness. Is your work filling a much-needed gap in the world of Open
Source hardware design? Something that was not there before?</li>
</ul>

<p>See the <a href="http://librecores.org/designcontest">design contest site</a> for full
details. The deadline for submission is August 31st, 2016. Entrants will have
the opportunity to present their work at <a href="http://openrisc.io/orconf/">ORConf</a>,
with some travel funding available thanks to the sponsors.</p>

<p>This neatly leads me to the next activity I wanted to highlight in this post.
Again, thanks to the hard work of our friends at FOSSi, registration is <a href="http://openrisc.io/orconf/">now
open for ORConf 2016</a>. To quote that page: &ldquo;ORCONF
is an open source digital design and embedded systems conference, covering
areas of electronics from the transistor level up to Linux user space and
beyond.  Expect presentations and discussion on free and open source IP
projects, implementations on FPGA and in silicon, verification, EDA tools,
licensing and embedded software&rdquo;.</p>

<p><a href="http://openrisc.io/orconf/2015/">Last year&rsquo;s ORConf</a> was the biggest and most
enthusiastic event focused on open source digital design I&rsquo;ve ever been to,
and saw the birth of the FOSSi Foundation. Please do register to attend and
submit talks. With the growing interest in open source hardware and open
source digital logic design, I expect it will be even bigger and better than
last year. ORConf 2016 will be held at the University of Bologna in Italy
between October 7th and October 9th. <a href="http://openrisc.io/orconf/">Register
now</a>.</p>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>lowRISC&#39;s 2016 Google Summer of Code Students</title><link>https://www.lowrisc.org/blog/2016/06/lowriscs-2016-google-summer-of-code-students/</link><guid>https://www.lowrisc.org/blog/2016/06/lowriscs-2016-google-summer-of-code-students/</guid><pubDate>Fri, 03 Jun 2016 12:12:49 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>The 2016 Google Summer of Code is now
<a href="https://developers.google.com/open-source/gsoc/timeline">underway</a> and we&rsquo;re
delighted to be working with five students, covering a variety of interesting
projects. They have all introduced themselves over the past few weeks on <a href="https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/lowrisc-dev-lists.lowrisc.org">our
project mailing
list</a>.
Many thanks to everyone who applied, to the mentors who volunteered, and to
Google for sponsoring this programme. If your application was unsuccessful, I
hope you&rsquo;ll try again next year.</p>

<p>The <a href="https://summerofcode.withgoogle.com/organizations/6271463900315648/">projects for lowRISC in the 2016
GSoC</a>
are:</p>

<ul>
<li>Porting the Arduino library to RISC-V (PULPino). Mahmoud Elmohr, mentored by
Andreas Traber</li>
<li>Implementing an open-source DDRx controller. Bittu N, mentored by Wei Song</li>
<li>Porting Musl libc to RISC-V. Masanori Ogino, mentored by Rich Felker. See
Masanori&rsquo;s <a href="http://article.gmane.org/gmane.comp.hardware.lowrisc.devel/377">first status
update</a></li>
<li>Porting the OP-TEE Trusted Execution Environment to the lowRISC
platform.Rahul S Mahadev, mentored by Stefan Wallentowitz. See <a href="http://mahadevrahul.blogspot.co.uk/2016/05/trusted-execution-environment-on-sel4.html">Rahul&rsquo;s blog
post</a>
on starting this project.</li>
<li>Porting the xv6 teaching operating system to the lowRISC platform. Jeff
Rogers, mentored by Alex Bradbury</li>
</ul>
 ]]></description></item><item><title>Apply now to work with lowRISC in Google Summer of Code</title><link>https://www.lowrisc.org/blog/2016/03/apply-now-to-work-with-lowrisc-in-google-summer-of-code/</link><guid>https://www.lowrisc.org/blog/2016/03/apply-now-to-work-with-lowrisc-in-google-summer-of-code/</guid><pubDate>Sun, 20 Mar 2016 20:35:57 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>We are very grateful to have been selected to take part as a mentoring
organisation in the <a href="https://summerofcode.withgoogle.com/">Google Summer of
Code</a> for the second year running. As
with last year, we&rsquo;re working with a number of friends from across the wider
open source hardware community to act as an umbrella for a range of
hardware-related projects. If you are a student who would like to be paid to
work on open source during the summer, then take a look at <a href="https://www.lowrisc.org/docs/gsoc-2016-ideas/">the lowRISC ideas
list</a> and
<a href="https://summerofcode.withgoogle.com/organizations/6271463900315648/">apply</a>.
As was pointed out on the Google Open Source Program&rsquo;s blog, there is a <a href="http://google-opensource.blogspot.co.uk/2016/03/something-different-code-up-hardware-in.html">good
showing from hardware-related projects in GSoC this
year</a>.
The deadline for applications is this coming Friday, 25th March at 7pm GMT.</p>

<p>We welcome ideas of your own creation, but the <a href="https://www.lowrisc.org/docs/gsoc-2016-ideas/">ideas we&rsquo;ve suggested this
year</a> include:</p>

<ul>
<li>A trace debug analysis tool (ideally using TypeScript and Electron)</li>
<li>Improving device-tree support for the Linux RISC-V port</li>
<li>Various ideas related to the <a href="http://www.clifford.at/yosys/">Yosys</a>
open-source synthesis tool.</li>
<li>Porting a teaching OS such as xv6 or XINU to the lowRISC platform</li>
<li>Porting CMSIS-DSP to PULPino</li>
<li>Doom on PULPino</li>
<li>Porting the Arduino libraries to PULPino</li>
<li>Integrating additional open-source IP for lowRISC on FPGA</li>
<li>Implementing a Trusted Execution Environment</li>
<li>Porting musl libc to RISC-V</li>
<li>A Generic hardware/software interface for software-defined radio</li>
<li>A SPIR-V frontend for Nyuzi</li>
<li>Porting an OS kernel to Nyuzi</li>
</ul>
 ]]></description></item><item><title>Third RISC-V Workshop: Day Two</title><link>https://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-two/</link><guid>https://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-two/</guid><pubDate>Wed, 06 Jan 2016 17:05:57 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>Today is the second day of the <a href="https://riscv.org/2015/12/prelim-agenda-3rd-risc-v-workshop/">third RISC-V
workshop</a>. Again, I&rsquo;ll be keeping a
semi-live blog of talks and announcements throughout the day. See
<a href="https://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one">here</a> for
notes from the first day.</p>

<h2 id="risc-v-asic-and-fpga-implementations-richard-herveille:de52cac55f5971e5407711238e57a2f4">RISC-V ASIC and FPGA implementations: Richard Herveille</h2>

<ul>
<li>Look for freedom of design. Want to free migrate between FPGAs, structured
ASICs, standard cell ASICs</li>
<li>Want to make it easier to migrate FPGAs to ASICs for advantages in price,
performance, power, IP protection.</li>
<li>Roa Logic&rsquo;s RV32I/64 implementations are called RV11 and RV22. RV11 is
in-order, single-issue, single thread. RV22 is in-order, dual-issue and dual
thread.</li>
<li>Implement a &lsquo;folded&rsquo; optimizing 5-stage pipeline, where some classic RISC
stages are folded together for performance improvement. e.g. the instruction
decode stage decides if the instruction sequence can be optimized.</li>
<li>Ported a debug unit for or1k from OpenCores</li>
<li>Mostly target the eASIC nextreme platform. Start with an existing FPGA
design, then transfer.</li>
<li>Achieved Fmax of 649MHz (32-bit core) on a nextreme-3, vs 114MHz on the customer&rsquo;s
current CYCLONE-V. Achieved a 70% power reduction.</li>
<li>Next steps are to improve resource utilization, increase offering of
extensions, and add multi-threading and multi-issue.</li>
</ul>

<h2 id="lowrisc-plans-for-risc-v-in-2016-alex-bradbury:de52cac55f5971e5407711238e57a2f4">lowRISC: plans for RISC-V in 2016: Alex Bradbury</h2>

<ul>
<li>Find my slides
<a href="https://speakerdeck.com/asb/lowrisc-plans-for-risc-v-in-2016">here</a>.
Apologies for not live-blogging my own talk.</li>
</ul>

<h2 id="a-32-bit-100mhz-risc-v-microcontroller-with-10-bit-sar-adc-in-130nm-gp-elkim-roa:de52cac55f5971e5407711238e57a2f4">A 32-bit 100MHz RISC-V microcontroller with 10-bit SAR ADC in 130nm GP: Elkim Roa</h2>

<ul>
<li>Current goal: a low-footprint RISC-V microcontroller like EFM32 or SAMD11
with USB low-speed PHY on-chip.</li>
<li>Looked at picorv32 and vscale, but ultimately implemented their own
implementation. Also adding in a 10-bit SAR ADC, DAC, PLL, GPIO.</li>
<li>Implement RV32IM using a 3-stage pipeline. IRQ handling is adapted from the
picorv32 timer.</li>
<li>Provides AXI-4 lite and an APB bridge.</li>
<li>SAR ADC intends to be fully synthesizable, 10-bit 10MHz.</li>
<li>The chip was taped out in October 2015 on 130nm TSMC GP. The core+interfaces
area was 800um x 480um.</li>
<li>Undertook a large effort on verification, implemented verification
testbenches for AXI-4 and APB peripheral functionality. Would like to partner
to get access to proven VIP.</li>
<li>Future work to be done on a USB PHY low-speed interface, DMA channels,
watchdog timer, eNVM 1-poly ROM</li>
<li>Question: where and when can I download it? Soon! Still cleaning it up.</li>
</ul>

<h2 id="soc-for-satelline-navigation-unit-based-on-the-risc-v-single-core-rocket-chip-sergei-khabarov:de52cac55f5971e5407711238e57a2f4">SoC for satelline navigation unit based on the RISC-V single-core Rocket chip: Sergei Khabarov</h2>

<ul>
<li>Currently have an RF-mezzanine card for FPGA prototypes, and
silicon-verified GNSS IP and ASIC development board with a LEON3 CPU inside.</li>
<li>On the software, have universal receive firmware and plug-and-play support
for different targets. Plus a host application for data analysis. See
gnss-snsor.com.</li>
<li>Now transitioning from the previous 180nm ASIC to a new 90nm chip with a
RISC-V core. The target frequency is 300MHz.</li>
<li>The new SoC design aims to take the best ideas of the GPL-licensed grlib
library (Gaisler Research) and will be written in VHDL.</li>
<li>Current code can be found <a href="https://github.com/sergeykhbr/riscv_vhdl">here</a>.</li>
<li>Plug and play approach taken from grlib to help quickly assemble a complex
SoC design. Device ID, vendor ID, address and interrupt configuration,
cacheability etc etc routed in sideband signals accessible via a dedicated
slave device on a system bus.</li>
<li>Some memory access optimizations have been implemented to allow access to
AXI peripherals in one clock cycle.</li>
<li>Implemented (or implementing?) the multi-core debug protocol, potentially
supported by Trace32 (Lauterbach).</li>
</ul>

<h2 id="risc-v-photonic-processor-chen-sun:de52cac55f5971e5407711238e57a2f4">RISC-V photonic processor: Chen Sun</h2>

<ul>
<li>Process scaling has helped massively for data transfer within a chip, but
we&rsquo;ve had little improvement for moving data off-chip.</li>
<li>The I/O wall involves being both power and pin limited. Silicon photonics
may help overcome this.</li>
<li>Started by tring to provide DRAM connected by photonics (as part of the
DARPA POEM project).</li>
<li>What about the foundry? Do it without a foundry. How to connect electronics
and photonics? Put them on the same chip. Where are you going to get a
processor? RISC-V!</li>
<li>They produced it and it was published in Nature last month. Dual-core
1.65GHz RISC-V. Manufactured in a commercial SOI process.</li>
<li>Build a waveguide with planar silicon processing. Silicon is the high-index
core. Oxides form the low-index cladding.</li>
<li>Transmitter is driven by a CMOS logic inverter. 5Gb/s data rate at 30fj/b.</li>
<li>Issue with ring resonators is massive variation based on process and
temperature variation. Need to stabilise this some-how. Add thermal tuning.</li>
<li>To demonstrate the optical memory system, had a second chip emulating a DRAM
controller.</li>
<li>We proposed an architecture, built it, and got performance competitive to
our predictions!</li>
</ul>

<h2 id="untethering-the-risc-v-rocket-chip-wei-song:de52cac55f5971e5407711238e57a2f4">Untethering the RISC-V Rocket Chip: Wei Song</h2>

<ul>
<li>Rocket is an open-source SoC generator from Berkeley. The base Rocket core
is a <sup>5</sup>&frasl;<sub>6</sub> stage single-issue in-order processor.</li>
<li>Previously an host-target interface was connected to the L2 bus which
communicates with an ARM core on the Zynq to provide peripherals.</li>
<li>The untethered Rocket chip adds a separate I/O bus. Currently uses Xilinx IP
for peripherals. First stage bootloader is on FPGA block RAM, second stage
bootloader is loaded from SD. I/O read and write are totally uncached.</li>
<li>The top-level (including I/O devices) is all in System Verilog. There is a
separate &lsquo;Chisel island&rsquo; containing the Rocket interface.</li>
<li>The I/O and memory maps can be configured by CSRs.</li>
<li>The first-stage bootloader copies the second stage to DRAM, performing an
uncached copy. It then remaps the DRAM to memory address 0, resets Rocket and
starts the second stage. The second stage uses a version of the Berkeley
bootloader. It starts multi-core, VM support, then loads and boots RISC-V
Linux in a virtual address space.</li>
<li>Currently the second stage bootloader stays resident to handle HTIF
requests.</li>
<li>Our code release contains a very detailed tutorial. Key features include
support for the Nexys4 as well as the more expensive KC705. You can also use
Verilator for simulation and a free WebPACK Vivado license.</li>
<li>The code release includes a rewritten TileLink/NASTI interface, DDR2/3
controller, SD, UART.</li>
<li>Future work: re-integrate tagged memory, remove HTIF from Linux kernel (help
wanted), interrupt controller, trace debugger (Stefan Wallentowitz),
run-control debug (SiFive), platform spec.</li>
</ul>

<h2 id="mit-s-riscy-expedition-andy-wright:de52cac55f5971e5407711238e57a2f4">MIT&rsquo;s RISCY expedition: Andy Wright</h2>

<ul>
<li>MIT implemented an IMAFD 64-bit RISC-V processor in Bluespec System Verilog.
It supports machine, supervisor, and user modes, boots Linux, and has been
tandem-verified with Spike.</li>
<li>Want to work on formal specification of the ISA, formally verified processor
implementations, memory consistency models, accelerators, microarchitecture
exploration, VLSI implementations using a standard ASIC flow.</li>
<li>Philosophy: get a working processor first, figure out why it&rsquo;s slow, and
make it faster without breaking it.</li>
<li>Moving to work on formal verification, which requests a formal specification
for RISC-V. Lots of questions to be answered, e.g. whether referenced bits in
page table entries should be set for speculatively accessed pages.</li>
<li>A single instruction can result in up to 13 effective memory accesses - how
do these interact with each other, and how do they influence the memory model?</li>
<li>Want simple operational definitions where legal behaviours can be observable
on a simple abstract machine consisting of cores and a shared monolithic
memory.</li>
<li>Looked at defining WMM, a new easy-to-specify weak consistency model.</li>
<li>Propose there should be a new instruction similar to sfence.vm, but going in
the opposite direction.</li>
<li>See also <a href="http://csg.csail.mit.edu/riscy-e/">their website</a>.</li>
<li>Question: will it be open source? Concerned currently because some aspects
of the design are used as challenges for student projects and releasing it
could compromise the projects.</li>
</ul>

<h2 id="pydgin-for-risc-v-a-fast-and-productive-instruction-set-simulator-berkin-ilbeyi:de52cac55f5971e5407711238e57a2f4">Pydgin for RISC-V, a fast and productive instruction-set simulator: Berkin Ilbeyi</h2>

<ul>
<li>Simple interpreted instruction set simulators get 1-10MIPS of performance.
Typical dynamic binary translation may achieve 100s of MIPS, with QEMU
achieving up to 1000 MIPS.</li>
<li>Another aspect worthy of consideration is productivity when working with the
simulator, for instance when looking to extend it to explore new hardware
features. Can you achieve high developer productivity and runtime performance?</li>
<li>Observe there are similar productivity-performance challenges for building
high performance language runtimes as for simulators. e.g. the PyPy project.</li>
<li>Pydgin uses PyPy&rsquo;s RPython framework.</li>
<li>Pydgin describes its own architectural description language (really a Python
DSL).</li>
<li>Pydgin running on a standard Python interpreter gives ~100KIPS. But when
going through RPython this gives 10MIPS. When targeting the RPython JIT,
adding extra RPython JIT hints are added achieved up to a 23x performance
improvement over no annotations.</li>
<li>Performs 2-3x better than Spike for many workloads. Spike caches decoded
instructions and uses PC-indexed dispatch to improve performance.</li>
<li>Achieved a 100MIPS+ RISC-V port after 9 days of development.</li>
<li>Pydgin is used in the Cornell research group to gain statistics for
software-defined regions, experimentations with data-structure specialisation,
control and memory divergence for SIMD, and more.</li>
<li>Pydgin is <a href="https://github.com/cornell-brg/pydgin">online at Github</a>.</li>
</ul>

<h2 id="orca-fpga-optimized-risc-v-soft-processors-guy-lemieux:de52cac55f5971e5407711238e57a2f4">ORCA, FPGA-optimized RISC-V soft processors: Guy Lemieux</h2>

<ul>
<li>ORCA is completely open-source. See it <a href="https://github.com/cornell-brg/pydgin">at
Github</a>.</li>
<li>Initially targeted the Lattice iCE40 (3.5kLUTs, under $5 in low quantities).</li>
<li>RV32M implemented in 2kLUTs at around 20MHz on the iCE40.</li>
<li>ORCA is highly parameterized, ideally suitable for FPGAs, portable across
FPGA vendors, and BSD-licensed.</li>
<li>Achieved 244MHz, 212MIPS on an Altera Stratix-V. Lots of room for further
improvements.</li>
<li>Clock speed is close to matching the picorv32 clock speed, but with higher
DMIPS/MHz.</li>
<li>Found 64-bit vs 32-bit counters added a lot of area.</li>
<li>A good FPGA implementation often leads to a good ASIC implementation, but a
good ASIC implementation often leads to a poor FPGA implementation.</li>
<li>Use dual-ported block RAMS on the FPGA for the register file.</li>
<li>Observe that reduced register count in RV32E makes no difference for FPGAs.
Divide is very expensive.</li>
<li>Beware when writing software, a shift could be as slow as 1b/cycle.</li>
<li>The privileged architecture spec contains too many CSRs and the 64bit
counters are too big, putting pressure on multiplexers. For FPGAs, perhaps
defined small/med/full versions.</li>
</ul>

<h2 id="pulpino-a-small-single-core-risc-v-soc-andreas-traber:de52cac55f5971e5407711238e57a2f4">PULPino, a small single-core RISC-V SoC: Andreas Traber</h2>

<ul>
<li>PULP and PULPino developed at ETH Zurich and University of Bologna with many
partners.</li>
<li>Develop an ultra low power processor for computing IoT. Explot parallelism
using multiple small simple cores organised in clusters.</li>
<li>Share memory within the cluster.</li>
<li>Support near-threshold operation for very low power.</li>
<li>PULP has been taped out over a dozen times across multiple process
technologies, down to 28nm.</li>
<li>PULP has a large number of IPs. To start with, open source PULPino as a
starting point.</li>
<li>PULPino is a microcontroller-style platform. No caches, no memory hierarchy,
no DMA. It re-uses IP from the PULP project and will be taped out in 65nm UMC.</li>
<li>The boot ROM loads a program from SPI flash.</li>
<li>Motivated to switch to RISC-V due to more modern design (no set flags, no
delay slot), compressed instructions, easily extensible.</li>
<li>Looking to extend RISC-V with non-standard extensions for hardware loops,
post-increment load+store, multiply-accumulate, ALU extensions (min, max
absolute value).</li>
<li>RI5CY core has full support for RV32I, implements just the mul from RV32M.
It has a 4 stage pipeline.</li>
<li>Performed a comparison based on published Cortex M4 numbers. RI5CY is a
little faster and a little smaller.</li>
<li>The RI5CY core itself is just 7% of the area of a PULPino SoC (assuming
32KiB instruction and data RAM).</li>
<li>Open source release will follow shortly, including a FreeRTOS port. Using
the Solderpad license. Just awaiting final approval from the University
(expected by the end of the month).</li>
<li>Want to port PULPino to IP-XACT. Also want to add floating point support,
branch prediction, and evaluate further non-standard ISA extensions.</li>
</ul>

<h2 id="the-berkeley-out-of-order-machine-boom-christopher-celio:de52cac55f5971e5407711238e57a2f4">The Berkeley Out-of-Order Machine (BOOM): Christopher Celio</h2>

<ul>
<li>An out-of-order core. It&rsquo;s synthesizable, parameterizable, and open-source.</li>
<li>Out-of-order is great for tolerating variable latencies, finding
instruction-level parallelism, and working with poor compilers or lazily
written code.</li>
<li>Downsides are it&rsquo;s more complex and potentially expensive in area and power.</li>
<li>Should work as an interesting baseline for micro-architecture research. Also
enables research that need and out of order core (e.g. on memory systems,
accelerators, VLSI methodologies).</li>
<li>BOOM implements IMAFD and the RV64G+ privileged spec.</li>
<li>The RISC-V ISA is easy to implement. Relaxed memory model, accrued FP
exception flags, no integer side-effects (e.g. condition codes), no cmov or
predication, no implicit register specifiers, rs1+rs2+rs3+rd are always in the
same space allowing decode and rename to proceed in parallel.</li>
<li>As Rocket-chip gets better, so does BOOM.</li>
<li>The host-target interface is being removed from rocket-chip to provide an
untethered system.</li>
<li>BOOM has a unified physical register file (floating point and integer).</li>
<li>Masses of parameters can be tweaked.</li>
<li>2-wide BOOM with 16KiB L1 caches 1.2mm2 in TSMC 45nm. Can clock at 1.5GHz
for two-wide.</li>
<li>Currently designed for single-cycle SRAM access as the critical path.</li>
<li>Planning on a tapeout later this year.</li>
<li>Achieve 50MHz on an FPGA where the bottleneck is the FPGA tools can&rsquo;t
register-rename the FPU.</li>
<li>BOOM is 9kloc, plus 11kloc from Rocket.</li>
<li>9% CoreMarks/MHz for ARM Cortex-A9 with similar architectural parameters and
smaller (but lacking the NEON unit). Power is also similar based on public
numbers.</li>
<li>Don&rsquo;t yet have a SPEC score. Need more DRAM on the FPGA and DRAM emulation.
With a cluster of FPGAs, this should only take about a day to run.</li>
<li>BOOM-chip is currently a branch of rocket-chip. See the slides for how to
get going.</li>
<li>Currently test/verify using riscv-tests, coremark, spec, and the
riscv-torture tool.</li>
<li>riscv-torture, a randomised test generator was open-sourced yesterday. If it
finds a bug, it will minimise the program for you.</li>
<li>A design document is a work in progress up on github.com/ccelio (doesn&rsquo;t
seem to be published yet?)</li>
<li>Want to grow a community of &ldquo;baby BOOMers&rdquo; :)</li>
</ul>

<h2 id="bluespec-s-risc-v-factory-rishiyur-nikhil:de52cac55f5971e5407711238e57a2f4">Bluespec&rsquo;s &ldquo;RISC-V Factory&rdquo;: Rishiyur Nikhil</h2>

<ul>
<li>Bluespec&rsquo;s &lsquo;RISC-V Factory&rsquo; is aimed at organisations who want to create
their own RISC-V based CPUs or SoCs without the usual learning curve, startup
costs, and ownership costs.</li>
<li>Currently working with Draper on the DOVER project we&rsquo;ll be hearing about in
the next talk.</li>
<li>The Flute RISC-V CPU has interfaces for direct GDB control, an elastic
(latency-insensitive) pipeline, hooks for optional tagged data.</li>
<li>Have components such as interconnect, memory controller, DMA engine,
devices. Working on flash for booting and Ethernet.</li>
<li>Provide a complete development and verification environment.</li>
</ul>

<h2 id="dover-a-metadata-extended-risc-v-andre-dehon:de52cac55f5971e5407711238e57a2f4">DOVER, a metadata-extended RISC-V: Andre DeHon</h2>

<ul>
<li>Current computer systems are insecure, and the processor architecture
contributes by blinding running code and making the secure and safe thing
expensive.</li>
<li>Add software defined metadata processing as implemented in PUMP.</li>
<li>Give each word a programmable tag. This is indivisible from a word and its
interpretation is programmable.</li>
<li>PUMP is a function from (Opcode, PCtag, Instrtag, RS1tag, RS2tag, MRtag) to
(Allowed?, PCtag, Resulttag).</li>
<li>Possible policies include access control, types, fine-grained instruction
permissions, memory safety, control flow integrity, taint tracking and
information flow control.</li>
<li>Rules are installed by software on PUMP misses. This demands metadata
structures be immutable.</li>
<li>A metadata tag can be a pointer, meaning it can point to a data structure of
arbitrary size.</li>
<li>Can support composite policies. i.e. no limit of only one policy at once.</li>
<li>There are no instructions to read or write metadata, i.e. no set-tag or read
tag. All tag manipulation is done through the PUMP.</li>
<li>In RISC-V use PUMP CSRs for rule inputs and outputs.</li>
<li>Compared to lowRISC: lowRISC has a limited number of tag bits, tags are
accessible to user code. Good for self-protection safety but argue it&rsquo;s not
adequate to enforce policies against malicious code (i.e. code actively trying
to circumvent protection).</li>
<li>Compare to Oracle M7. M7 has a limited number of colors and a fixed policy.</li>
<li>Have some global tags and rules so they have the same meaning across
different processes.</li>
<li>Idiosyncrasies about RISC-V: one instruction uses RS3, sparse opcode space
increases table size, multiple instructions per machine word (policies want
tagged instructions)</li>
<li>Draper plans to make available Bluespec RISC-V and metadata changes, PUMP,
set of basic micropolicies, runtime support and tools all under open source
licenses.</li>
<li>Building a consortium around Dover, an &ldquo;Inherently Secure Processing Hive&rdquo;.</li>
<li>Question: what is the overhead? Don&rsquo;t have figures yet for RISC-V. From
previous work, have 10% area overhead and twice the area, 60% energy overhead.</li>
</ul>
 ]]></description></item><item><title>Third RISC-V Workshop: Day One</title><link>https://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/</link><guid>https://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/</guid><pubDate>Tue, 05 Jan 2016 17:35:57 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2015/12/prelim-agenda-3rd-risc-v-workshop/">third RISC-V workshop</a> is going
on today and tomorrow at the Oracle Conference Center, California. I&rsquo;ll be
keeping a semi-live blog of talks and announcements throughout the day. See
<a href="https://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-two">here</a> for
notes from the second day.</p>

<h2 id="introductions-and-risc-v-foundation-overview-rick-o-connor:6ba2032c06bf883b3d2851c8414b058c">Introductions and RISC-V Foundation Overview: Rick O&rsquo;Connor</h2>

<ul>
<li>Save the date, the 4th RISC-V workshop will be July 12th-13th at the MIT
CSAIL/Stata Center.</li>
<li>In August 2015, articles of incorporation were filed to create a non-profit
RISC-V Foundation to govern the ISA.</li>
<li>RISC-V Foundation mission statement: The RISC-V Foundation is a non-profit
consortium chartered to standardize, protect, and promote the free and open
RISC-V instruction set architecture together with its hardware and software
ecosystem for use in all computing devices.</li>
<li>The RISC-V ISA and related standards shall remain open and license-free to
all parties.</li>
<li>The compatibility test suites shall always be publicly available as a source
code download.</li>
<li>To protect the standard, only members (with commercial RISC-V products) of
the Foundation in good standing can use &ldquo;RISC-V&rdquo; and associated trademarks,
and only for devices that pass the tests in the open-source compatibility
suites maintained by the Foundation.</li>
<li>Drafting a new license for the ISA &lsquo;combining the best of BSD, GPL and so
on&rsquo;.</li>
<li>The Foundation will have a board of 7 directors elected by the members. All
members of committees must be members of the RISC-V Foundation.</li>
<li>All details of the foundation are a work in progress. Feedback is welcome!</li>
<li>16 member companies so far. Bluespec, Draper, Google, Hewlett Packard Labs,
Microsemi, Oracle, SiFive, antmicro, codasip, Gray Research, Lattice
Semiconductor, lowRISC, ROA logic, Rumble Development, Syntacore, Technolution</li>
</ul>

<h2 id="risc-v-updates-krste-asanovic:6ba2032c06bf883b3d2851c8414b058c">RISC-V Updates: Krste Asanovic</h2>

<ul>
<li>The 1.9 version of the compressed extension is on track to become frozen and
become blessed as v2.0. Now is the time to speak up if you have any feedback
or concerns!</li>
<li>Privileged architecture 1.7 was released in May 2015 and has received a lot
of feedback. Hope to release an updated draft addressing feedback in the next
month or two. Doubt it will really settle down before the summer, as it needs
more OS and driver development against it.</li>
<li>&lsquo;V&rsquo; Vector Extension: not yet ready to release a draft for this workshop,
but the RTL of the HWacha vector coprocessor has been open-sourced along with
3 tech-reports.</li>
<li>Hwacha is NOT the V extensions. It&rsquo;s a research project designed to push the
limits of in-order decoupled data-parallel accelerators (e.g. GPUs). The
microarchitecture does demonstrate some of the ideas that will appear in V.</li>
<li>Ongoing ISA research at UCB: virtual local store (VLS, Henry Cook&rsquo;s 2009
master&rsquo;s thesis) and user-level DMA (copying data between DRAM and VLS
directly).</li>
<li>New Berkeley open-source cores: BOOM out-of-order implementation and V-Scale
(verilog implementation of Z-Scale).</li>
<li>RISC-V is being transitioned out of Berkeley. This involves upstreaming of
tools and the RISC-V Foundation taking over the standards process.</li>
<li>SiFive has been founded by some of the lead RISC-V developers (Krste
Asanovic, Yunsup Lee, Andrew Waterman). Sutter Hill Ventures have invested.</li>
<li>Most urgent outstanding issues: holes and ambiguities in the specification
and the platform specification.</li>
<li>Holes in the spec: floating-point NaNs (resolved and updated), CSR
read/write semantics (resolved, updated spec), memory model (far from
resolved), Hypervisor support (no proposal). A formal spec of the whole ISA
and memory model is desired.</li>
<li>Although RISC-V was designed in reusable layers, some concrete standards for
hardware platforms are desirable e.g. memory maps, interrupt controller, power
management. To what extent can platform specs be shared across
microcontroller-class, application cores, and rack-scale designs?</li>
</ul>

<h2 id="risc-v-external-debug-aka-jtag-debugging-tim-newsome:6ba2032c06bf883b3d2851c8414b058c">RISC-V External Debug (aka JTAG debugging): Tim Newsome</h2>

<ul>
<li>Goals: a debug system that works for everybody with a working system done by
July 1st 2016.</li>
<li>The specification will be submitted to the RISC-V Foundation and there are
plans for an open source release of the debugger and implementations for
Rocket and Z-Scale.</li>
<li>Status: the specification is mostly complete.</li>
<li>Features: (many, see the slides). Interested in tracing core execution to on
or off-chip RAM and providing a framework to debug any component on the
system, not just the RISC-V cores.</li>
<li>The debug transport module provides access to the system bus. It implements
a message queue and optional authentication.</li>
<li>New CSRs will be added and exposed on the system bus.</li>
<li>The spec describes a small amount of debug memory (1KiB ROM) and 8-16 bytes
of RAM. This memory is not cached and is shared between all cores.</li>
<li>Up to 4095 hardware breakpoints supported (but 4 is more typical). Each may
support exact address match, address range match, exact data match, data range
match, &hellip;</li>
<li>The work-in-progress spec will be posted to the hw-dev RISC-V mailing list
later today. Comments very welcome.</li>
<li>Question: how does this map to gdb&rsquo;s capabilities? Are there things it can
do but gdb can&rsquo;t or vice-versa? It&rsquo;s not a 1:1 match but should be a superset
of what gdb can do.</li>
<li>Question: how does the tracing scale? Hasn&rsquo;t be investigated yet.</li>
<li>Question: will support be integrated into the BOOM codebase? Answer: not
currently planned.</li>
<li>Question: there&rsquo;s a wide spectrum of functionality that different
implementations could implement. Is there a discovery mechanism for the
functionality that is supported? Yes.</li>
</ul>

<h2 id="risc-v-in-axiom-michael-gielda:6ba2032c06bf883b3d2851c8414b058c">RISC-V in Axiom: Michael Gielda</h2>

<ul>
<li>Axiom is a fully open source 4K film camera design. It is an EU Horizon 2020
project with multiple partners.</li>
<li>Aim of Axiom is to create an extensible open source platform that is also a
desirable project in itself. The aim is to open up what is currently a fairly
closed industry and lower barriers of entry to new players. There is an
obvious parallel to the RISC-V and lowRISC projects.</li>
<li>Chose the largest Zynq FPGA that had zero-cost tool support to maximise the
number of people who can hack on the design.</li>
<li>Using the Z-Scale as a soft-core for communication between the FPGA
pre-processing board (Kintex-7) and the FPGA SoC main board with a dual-core
Cortex-A9 (Zynq 7030).</li>
<li>Long-term goals are to ensure the design can be reused through
parameterisation, and look at broadening adoption of the Chisel design
methodology.</li>
<li>The Axiom Gamma project is almost half-way done. There will be an EU
technical review in March at which point it should be working.</li>
</ul>

<h2 id="emulating-future-hpc-soc-architectures-using-risc-v-farzad-fatollahi-fard:6ba2032c06bf883b3d2851c8414b058c">Emulating future HPC SoC architectures using RISC-V: Farzad Fatollahi-Fard</h2>

<ul>
<li>Should HPC take inspiration from the embedded market?</li>
<li>Is building an SoC for HPC a good idea? HPC is power limited
(performance/Watt) which arguably means HPC and embedded requirements are
aligned.</li>
<li>From a previous project case study (Green Wave), they found an embedded SoC
design was performance/power competitive with Fermi. This had a 12x12 2D
on-chip torus network with 676 compute cores, 33 supervisor cores, 1 PCI
express interface, 8 Hybrid Memory Cube interfaces, &hellip;</li>
<li>Proposed an FPGA-implemented SoC for HPC. This contains 4 Z-scale processors
with a 2x2 concentrated mesh with 2 virtual channels. The Z-Scale was chosen
for area-efficiency on FPGA.</li>
<li>The network is implemented using the <a href="https://github.com/LBL-CoDEx/OpenSoCFabric">OpenSoC
fabric</a> (open source and in
chisel). AHB endpoints have now beed added and AXI is in-development.</li>
<li>A 96-core system was constructed using multiple FPGAs.</li>
<li>For more info, see <a href="http://www.codexhpc.org/">CoDEx HPC</a>.</li>
</ul>

<h2 id="grvi-phalanx-a-massively-parallel-risc-v-fpga-accelerator-jan-gray:6ba2032c06bf883b3d2851c8414b058c">GRVI Phalanx. A massively parallel RISC-V FPGA accelerator: Jan Gray</h2>

<ul>
<li>GRVI is pronounced &lsquo;groovy&rsquo;.</li>
<li>There&rsquo;s lots of interest in FPGA accelerators right now (Altera acquisition,
MSR&rsquo;s catapult).</li>
<li>FPGAs are an interesting platform. Massively parallel. Specialized.
Connected. High throughput. Low latency. The big barrier is of course porting
your software. Jan argues OpenCL for FPGAs is a major breakthrough for this
problem, if you&rsquo;re lucky enough to have an application that can be expressed
in OpenCL.</li>
<li>Phalanx is an accelerator accelerator - an infrastructure making it easier
to run you application on an FPGA and connect everything together. It is
composed of processor+accelerator clusters+NoC.</li>
<li>Jan&rsquo;s Razor: &ldquo;In a CMP, cut inessential resources from each CPU, to maximize
CPUs per die.&rdquo;</li>
<li>Jan has achieved an RV32I datapath in about 250 LUTs. This core can achieve
300-375MHz, 1.3-1.6CPI. The &lsquo;GRVI&rsquo; core is ~320 6-LUTs so &ldquo;1 MIPS/LUT&rdquo;.</li>
<li>How many can you fit on a modern FPGA? The limiting resource is really the
block RAMs. In a cluster, two processing elements can share an instruction
BRAM, and all PEs can share a cluster memory.</li>
<li>How should the clusters be interconnected? A 5-port virtual channel router
might be a sensible choice in an ASIC, but does not map well to an FPGA.
Instead use a <a href="http://fpga.org/2015/09/03/introducing-hoplite/">Hoplite</a> 2D
router. This is only 1% of the area x delay product of FPGA-optimized VC
routers. Each cluster has a 300 bit connection to the Hoplite router (with a
256bit payload).</li>
<li>400 of the GRVI Phalanx PEs can fit on a Xilinx KU040. The amortized cost of
the router per processor is only 40 LUTs.</li>
<li>Can fit 32 GRVI Phalanx PEs on an Artix-7-35T.</li>
<li>Want to support different accelerated parallel programming models: SPMD,
MIMD, MP. All potentially accelerated by custom GRVI And cluster function
units, custom memory or interconnects, custom accelerators on the NOC.</li>
<li>Next steps: debug/trace over NoC, Hoplite/AXI4 bridges, OpenCL stack,
potential bridge to Chisel RISC-V infrastructure?</li>
<li>Question: how do I get this? Not available yet, and not yet sure on the
licensing model.</li>
</ul>

<h2 id="coreboot-on-risc-v-ron-minnich:6ba2032c06bf883b3d2851c8414b058c">Coreboot on RISC-V: Ron Minnich</h2>

<ul>
<li>Initializing the stuff outside the main CPU on a chromebook takes about 1
billion instructions before it can start Linux.</li>
<li>Firmware, 1990-2005 &ldquo;fire and forget&rdquo;. Set al lthe stff kernels can&rsquo;t do
(e.g. LinuxBIOS), then get out of the way. But now there&rsquo;s a push for the
firmware to hang around after boot.</li>
<li>Ron argues this sucks. It&rsquo;s slow, there&rsquo;s no easy bugfix path, and it&rsquo;s not
SMP capable on x86.</li>
<li>Why doesn&rsquo;t Ron like persistent firmware? It&rsquo;s another attack vector,
indistinguishable from a persistent embedded threat. Ron&rsquo;s preference is the
platform management code run as a kernel thread. Minion cores are ideal for
this (Ron&rsquo;s words rather than mine - I of course agree whole-heartedly).</li>
<li>coreboot is a GPLv2 BIOS replacement (not a bootloader). It has multiple
possible payloads including SeaBIOS and depthcharge (used for verified boot on
Chromebooks).</li>
<li>Port was started in October 2014 as a side project. The effort resumed in
July 2015 with the privileged spec, and as-of September is up and running
again. The most recent port runs on Spike but not QEMU (due to lack of support
for the privileged spec).</li>
<li>RISC-V is a first class citizen in coreboot, all commits must pass tests for
the RISC-V buildbot.</li>
<li>src/arch/riscv is 2685 LoC.</li>
<li>The Federal Office for Information Security in Germany runs a hardware test
station for coreboot. As soon as real hardware is running, they&rsquo;ve offered to
integrate it into their system.</li>
<li>Lessons learned

<ul>
<li>provide a boot time SRAM (make sure the address is fixed and not aliased
by DRAM once DRAM is up).</li>
<li>Provide a serial port.</li>
<li>Ron reiterates that runtime functions belong in the kernel, not persistent
firmware.</li>
<li>Firmware tables always need translation by kernel, so make them text not
binary.</li>
<li>Keep the mask ROM as simple as possible.</li>
<li>Don&rsquo;t cheap out on SPI or flash part size. Just plan a 64MiB part.</li>
<li>Don&rsquo;t reset the chipset on IE device not present.</li>
</ul></li>
</ul>

<h2 id="risc-v-and-uefi-dong-wei-and-abner-chang:6ba2032c06bf883b3d2851c8414b058c">RISC-V and UEFI: Dong Wei and Abner Chang</h2>

<ul>
<li>There is a UEFI Forum consistent of a board of 12 directors, 12 promoters,
42 contributors, 213 adopters.</li>
<li>UEFI and ACPI are both now handled by the UEFI Forum.</li>
<li>A RISC-V UEFI port is taking place using EDKII (EFI Development Kit II) and
OVMF (Open Virtual Machine Firmware).</li>
<li>The speakers are giving a very thorough description of the UEFI boot
mechanism which I&rsquo;m not able to do justice. You&rsquo;re best waiting for the
slides+video I&rsquo;m afraid.</li>
<li>The project was started a few months ago, and can now boot to a UEFI shell.</li>
<li>They have created a new RISC-V QEMU target with some PC peripherals (CMOS,
PM, PCI and other devices), and also implemented RISC-V machine mode.</li>
<li>Requests for new RISC-V spec additions: a periodic timer CSR, RTC with alarm
CSR, PI management mode support, &hellip; (sorry, missed some).</li>
</ul>

<h2 id="freebsd-and-risc-v-ruslan-bukin:6ba2032c06bf883b3d2851c8414b058c">FreeBSD and RISC-V: Ruslan Bukin</h2>

<ul>
<li>FreeBSD will support RV64I in release 11.0.</li>
<li>Why use FreeBSD? Among other reasons, it gives a full-stack BSD license
(RISC-V, FreeBSD, LLVM/Clang).</li>
<li>FreeBSD has been brought up on Spike.</li>
<li>The early boot assembly code will put the hardware in a known state, build a
ring buffer for interrupts, initialise the page tables, enable the MMU, then
finally branch to a virtual address and call into C code.</li>
<li>Userspace porting required modifications to jemalloc, csu (crt1.S, crtn.S,
crti.S), libc, msun (libm), rtld-elf (the runtime linker).</li>
<li>The FreeBSD port is based on the ARMv8 port. It has a 25k line diff and took
6 months from scratch.</li>
<li>Userland started working in December. Support will now be committed to
FreeBSD SVN.</li>
<li>Next plans include multicore, FPU, increasing the virtual address space,
DTrace, performance monitoring counters, QEMU, &hellip;</li>
<li>Proposed changes: split sptbr to sptrbr0 and sptbr1 for the user VA and the
kernel VA. This means there is no need to change SPTBR when changing the
privilege level, and should reduce code size.</li>
<li>For more on the project, see the relevant <a href="https://wiki.freebsd.org/riscv">FreeBSD wiki
page</a>.</li>
</ul>

<h2 id="building-the-risc-v-software-ecosystem-arun-thomas:6ba2032c06bf883b3d2851c8414b058c">Building the RISC-V software ecosystem: Arun Thomas</h2>

<ul>
<li>&ldquo;2016 is the year of RISC-V&rdquo;. Or at least, the year of RISC-V software. We
have a great opportunity to push the software stack forwards.</li>
<li>What can we achieve by the end of the year? Hopefully upstereamed GNU
toolchain and QEMU. More mature Clang/LLVM support, upstreamed OS support,
Debian/RISC-V port, start thinking about Android and a real-time OS.</li>
<li>How do we get there? We need to recruit more RISC-V developers and make it
easier for people to get started by producing more docs and specifications.</li>
<li>Right now, the RISC-V Github has had 48 contributors from a wide range of
Universities, companies and OSS projects.</li>
<li>We should present talks and tutorials at developer conferences and local
user group meetings.</li>
<li>If you have local patches, upstream them!</li>
<li>How to attract developers? Could fund developers/projects via the
Foundation, apply to be a Google Summer of Code mentoring organization, update
the list of open bugs and future requests on github and track contribution
statistics.</li>
<li>We can make it much easier for people to get started by building Debian
packages, upstreaming, and providing regular binary snapshots.</li>
<li>Spike is great for prototyping hardware features, but QEMU is a better tool
for software development and a critical part of the RISC-V software story.</li>
<li>There&rsquo;s more to specify. e.g. a platform specification (e.g. ARMv8 Server
Base System Architecture), boot architecture (look at the ARMv8 Server Base
Boot Requirements), RISC-V ABI, hypervisor, security.</li>
<li>Useful documents include a RISC-V Assembly Guide, some equivalent of the ARM
Cortex-A Programmer&rsquo;s Guide, and a New Contributor&rsquo;s Guide.</li>
</ul>
 ]]></description></item><item><title>Untethered lowRISC release</title><link>https://www.lowrisc.org/blog/2015/12/untethered-lowrisc-release/</link><guid>https://www.lowrisc.org/blog/2015/12/untethered-lowrisc-release/</guid><pubDate>Fri, 18 Dec 2015 10:30:00 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>Over the past several months, we&rsquo;ve been working to provide a standalone or
&lsquo;untethered&rsquo; SoC. Cores in the original <a href="https://github.com/ucb-bar/rocket-chip">Rocket
chip</a> rely on communicating with a
companion processor via the host-target interface (HTIF) to access peripherals
and I/O. This release removes this requirement, adding an I/O bus and
instantiating FPGA peripherals. The accompanying <a href="https://www.lowrisc.org/docs/untether-v0.2/">tutorial</a>, written by Wei Song, describes how to
build this code release and explains the underlying structural changes. We
support both the <a href="http://www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html">Xilinx
KC705</a> and
the lower-priced <a href="http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/">Nexys4
DDR</a>
development boards. We would gladly welcome assistance in supporting other
boards.</p>

<p>Please note that the codebase temporarily lacks support for tagged memory
included in the <a href="https://www.lowrisc.org/docs/tagged-memory-v0.1/">previous release</a>. We plan to re-integrate tagged memory support
with additional optimisations early next year. You can find a detailed list of
changes in the <a href="https://www.lowrisc.org/docs/untether-v0.2/release/">release notes</a>.
One highlight is support for <a href="https://www.lowrisc.org/docs/untether-v0.2/vsim/">RTL simulation using the open-source Verilator
tool</a>.</p>

<p>This development milestone should make it easier for others to contribute. If
you&rsquo;re looking to get stuck in, you might want to consider looking at tasks
such as:</p>

<ul>
<li>Cleaning up the <a href="https://github.com/lowRISC/riscv-linux">RISC-V Linux port</a>,
improving devicetree support and removing the host-target interface.</li>
<li>Replacing use of proprietary peripheral IP with open-source IP cores.</li>
<li>Adding support for different FPGA development boards, including Altera
boards.</li>
<li>Implementing the <a href="http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-852.pdf">BERI Programmable Interrupt
Controller</a> (p73), and
adding necessary Linux support.</li>
</ul>

<p>Our next development priorities are the re-integration of tagged memory
support and an initial integration of a minion core design. We also expect to
put out a job advert in the next few weeks for a new member of the lowRISC
development team at the University of Cambridge Computer Laboratory.
Interested applicants are encouraged to make informal enquiries about the post
to Rob Mullins <a href="mailto:Robert.Mullins@cl.cam.ac.uk">Robert.Mullins@cl.cam.ac.uk</a>.</p>

<p>We hope to see many of you at the <a href="https://riscv.org/2015/12/prelim-agenda-3rd-risc-v-workshop/">3rd RISC-V
Workshop</a> in January, where Wei Song
and Alex Bradbury will be presenting about lowRISC.</p>
 ]]></description></item><item><title>lowRISC at ORConf 2015</title><link>https://www.lowrisc.org/blog/2015/08/lowrisc-at-orconf-2015/</link><guid>https://www.lowrisc.org/blog/2015/08/lowrisc-at-orconf-2015/</guid><pubDate>Sun, 16 Aug 2015 10:51:14 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>Please join us October 9th-11th in Geneva, Switzerland for <a href="http://openrisc.io/orconf/">ORConf
2015</a>. The event is kindly being hosted by CERN at
the <a href="http://knowledgetransfer.web.cern.ch/ideasquare/about">IdeaSquare</a>.
Last year&rsquo;s ORConf was home to the first public talk on lowRISC and we&rsquo;re
delighted this year it will also be hosting a
series of lowRISC and RISC-V discussions, serving as a European lowRISC and
RISC-V workshop. ORConf has in recent years grown to cover a range of open
source hardware topics beyond the original OpenRISC focus. Expect
presentations and discussion on free and open source IP projects,
implementations on FPGA and in silicon, verification, EDA tools, licensing and
embedded software, to name a few.</p>

<p>The event will run from 13:00 until 18:30 on Friday, 09:30 until 19:30 on
Saturday, and from 09:30 until 15:30 on Sunday. Friday will consist primarily
of breakout sessions, planning, and discussion regarding lowRISC. If you are
already contributing or your are thinking of getting involved and want to
learn more, you are very welcome to join us. If you would like to present,
do submit a proposal either via the link at the <a href="http://openrisc.io/orconf/">ORConf
website</a> or to me at asb@lowrisc.org. We hope to
see many of you there - please <a href="http://goo.gl/forms/KRZux8vnyO">register
here</a>.</p>
 ]]></description></item><item><title>Second RISC-V Workshop: Day Two</title><link>https://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-two/</link><guid>https://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-two/</guid><pubDate>Tue, 30 Jun 2015 17:00:45 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>It&rsquo;s the second day of the <a href="https://riscv.org/2015/06/preliminary-agenda-for-the-2nd-risc-v-workshop-is-posted/">second RISC-V
workshop</a> today in Berkeley,
California.  I&rsquo;ll be keeping a semi-live blog of talks and announcements
throughout the day.</p>

<h2 id="z-scale-tiny-32-bit-risc-v-systems-yunsup-lee:567027a3c41d4c7f721c232ee28182e0">Z-scale. Tiny 32-bit RISC-V Systems: Yunsup Lee</h2>

<ul>
<li>Z-Scale is a family of tiny cores, similar in spirit to the ARM Cortex-M
family. It integrates with the AHB-Lite interconnect.</li>
<li>Contrast to Rocket (in-order cores, 64-bit, 32-bit, dual-issue options), and
BOOM (a family of out-of-order cores).</li>
<li>Z-Scale is a 32-bit 3-stage single-issue in-order pipeline executing the
RV32IM ISA.</li>
<li>The instruction bus and data base are 32-bit AHB-Lite buses</li>
<li>There is a plan to publish a microarchitecture specification to make it easy
for others to implement an equivalent design in the language of their choice.</li>
<li>The Zscale is slightly larger than the Cortex-M0 due to having 32 vs 16
registers, 64-bit performance counters, and a fast multiply and divide. The
plan is to add an option to generate a Zscale implementing RV32E (i.e. only
having 16 registers).</li>
<li>Zscale is only 604 loc in Chisel. 274 lines for control, 267 for the
datapath, and 63 for the top-level. Combine with 983loc borrowed from Rocket.</li>
<li>A Verilog implementation of Z-scale is being implemented. It&rsquo;s currently
1215 lines of code.</li>
<li>The repo is <a href="https://github.com/ucb-bar/zscale">here</a>, but Yunsup needs to
do a little more work to make it easily buildable. There will be a blog post
on the RISC-V site soon.</li>
<li>All future Rocket development will move to the public
<a href="https://github.com/ucb-bar/rocket-chip">rocket-chip</a> repo!</li>
<li>Memory interfaces:

<ul>
<li>TileLink is the Berkeley cache-coherent interconnect</li>
<li>NASTI (Berkeley implementation of AXI4)</li>
<li>HASTI (implementation of AHB-lite)</li>
<li>POCI (implementation of APB)</li>
</ul></li>
<li>The plan is to dump HTIF in Rocket, and add a standard JTAG debug interface.</li>
<li>Future work for Z-Scale includes a microarchitecture document, improving
performance, implementing the C extensions, adding an MMU option, and adding
more devices.</li>
</ul>

<h2 id="boom-berkeley-out-of-order-machine-chris-celio:567027a3c41d4c7f721c232ee28182e0">BOOM. Berkeley Out-of-order-Machine: Chris Celio</h2>

<ul>
<li>BOOM is a (work in progress) superscalar, out-of-order RISC-V processor
written in Chisel.</li>
<li>Chris argues there&rsquo;s been a general lack of effort in academia to build and
evaluate out-of-order designs. As he points out, much research relies on
software simulators with no area or power numbers.</li>
<li>Some of the difficult questions for BOOM are which benchmarks to use, and
how many cycles you need to run. He points out that mapping to FPGA running at
50MHz, it would take around a day for the SPEC benchmarks for a cluster of
FPGAs.</li>
<li>The fact that rs1, rs2, rs3 and rd are always in the same space in the
RISC-V ISA allows decode and rename to proceed in parallel.</li>
<li>BOOM supports the full RV64G standard. It benefits from reusing Rocket as a
library of components.</li>
<li>BOOM uses explicit renaming, with a unified register file holding both
x-regs and f-regs (floating point). A unified issue window holds all
instructions.</li>
<li>BOOM is synthesisable and hits 2GHz (30 FO4) in TSMC 45nm.</li>
<li>BOOM is 9kloc of its own code, and pulls in 11.5kloc from other libraries
(rocket, uncore, floating poing)</li>
<li>BOOM compares well to an ARM Cortex-A9 and A15 in terms of CoreMark/MHz. A
4-wide BOOM gives a similar CoreMark/MHz to the A15.</li>
<li>Future work will look at new applications, a ROCC interface, new
microarchitecture designs. The plan is to open source by this winter.</li>
</ul>

<h2 id="fabscalar-risc-v-rangeen-basu-roy-chowdhury:567027a3c41d4c7f721c232ee28182e0">Fabscalar RISC-V: Rangeen Basu Roy Chowdhury</h2>

<ul>
<li>A FabScalar RISC-V version should be released in the next few days</li>
<li>FabScalar generates synthesisable RTL for arbitrary superscalar cores with a
canonical superscalar template.</li>
<li>FabScalar uses a library of pipeline stages, providing many different
designs for each canonical pipeline stage.</li>
<li>Two chips have been built with FabScalar so far (using PISA).</li>
<li>The RISC-V port was built on the previous PIA &lsquo;Superset Core&rsquo;. This had
64-bit instructions and 32-bit address and data.</li>
<li>For RISC-V FabScalar they have a unified physical register file and unified
issue queue for floating point (so the FP ALU is treated like just another
functional unit).</li>
<li>FabScalar RISC-V will be released as an open source tool complete with
uncore components and verification infrastructure. It will be available on
GitHub in the fall.</li>
<li>The license isn&rsquo;t yet decided, but there&rsquo;s a good chance it will be BSD.</li>
</ul>

<h2 id="aristotle-a-logically-determined-clockless-risc-v-rv32i-matthew-kim:567027a3c41d4c7f721c232ee28182e0">Aristotle. A Logically Determined (Clockless) RISC-V RV32I: Matthew Kim</h2>

<ul>
<li>Two logical values are defined. Data and null (not data). Then define
threshold operators to produce &lsquo;null convention logic&rsquo;.</li>
<li>See <a href="https://users.soe.ucsc.edu/~scott/papers/NCL2.pdf">here</a> for more on
Null Convention Logic</li>
<li>This results in a system built entirely of combinational logic. I couldn&rsquo;t
hope to accurately summarise the work here. I&rsquo;m afraid you might be best off
waiting for the recording.</li>
<li>Current executing compiled quicksort at approximately 400mips (without
serious optimisation).</li>
</ul>

<h2 id="risc-v-erification-prashanth-mundkur:567027a3c41d4c7f721c232ee28182e0">RISC-V(erification): Prashanth Mundkur</h2>

<ul>
<li>Current architectures e.g. those from Intel and ARM have large errata sheets
published semi-regularly. Can we do better for RISC-V?</li>
<li>Need an unambiguous formal ISA specification which should be coupled to a
processor implementation amenable to the two, with a formal link between the
two.</li>
<li>Currently specifying RISC-V in the <a href="http://www.cl.cam.ac.uk/~acjf3/l3/">L3
DSL</a>. The interpreter is used as a
reference oracle for processor implementations.</li>
<li>The current state of the spec is <a href="https://github.com/pmundkur/l3riscv">available on
Github</a>.</li>
<li>The work has already helped to highlight some areas where clarification is
needed in the written specification</li>
<li>Next steps would involve support for the compressed instruction set and
floating point, booting Linux, and using for tandem-verification (e.g. with
Flue from Bluespec).</li>
<li>Hope to export usable HOL4 formal definitions, and use that to prove
information properties (e.g. non-interference and information flow in
low-level privileged code).</li>
<li>The talk is now moving to the second half, where Prashanth is presenting
Nirav Dave&rsquo;s work</li>
<li>This work is looking at rapidly verifying architectural and
micro-architectural variants of RISC-V. Rely on translating between
microarchitectural-states and ISA-level states.</li>
</ul>

<h2 id="towards-general-purpose-tagged-memory-wei-song:567027a3c41d4c7f721c232ee28182e0">Towards General-Purpose Tagged Memory: Wei Song</h2>

<ul>
<li>Wei Song is presenting his <a href="https://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/">work on tagged memory support in
lowRISC</a>.
I&rsquo;ll post the slides shortly.</li>
</ul>

<h2 id="raven3-a-28nm-risc-v-vector-processor-with-on-chip-dc-dc-convertors-brian-zimmer:567027a3c41d4c7f721c232ee28182e0">Raven3, a 28nm RISC-V Vector Processor with On-Chip DC/DC Convertors: Brian Zimmer</h2>

<ul>
<li>Support dynamic voltage and frequency scaling on-chip with no off-chip
components.</li>
<li>Want to switch all converters simultaneously to avoid charge sharing. The
clock frequency adapts to track the voltage ripple.</li>
<li>Raven has a RISC-V scalar core, vector accelerator. 16KB scalar instruction
cache, 32KB shared data cache, and 8KB instruction cache. This has a 1.19mm^2
area.</li>
<li>The converter area is 0.19mm^2</li>
<li>The chip was wire-bonded on to a daughter-board, which was then connected to
a larger motherboard connected to a Zedboard</li>
<li>Converter transitions are less than 20ns, which allows extremely
fine-grained DVFS.</li>
<li>Raven3 showed 80% efficiency across a wide voltage range and achieved
26GFLOPS/W using the on-chip conversion.</li>
</ul>

<h2 id="evaluating-risc-v-cores-for-pulp-an-open-parallel-ultra-low-power-platform-sven-stucki:567027a3c41d4c7f721c232ee28182e0">Evaluating RISC-V Cores for PULP. An Open Parallel Ultra-Low-Power Platform : Sven Stucki</h2>

<ul>
<li>Approximately 40 people working on PULP in some way</li>
<li>Ultimate (ambitious) goal is one 1GOPS/mW (or 1pJ/op). Also hope to achieve
energy proportionality.</li>
<li>Plan is to be open source on GitHub</li>
<li>PULP has been silicon-proven in 28nm, 65nm, 130nm and 180nm. The team have
tape-outs planned through to 2016.</li>
<li>Sven has replaced the OpenRISC frontend with a RISC-V decoder, hoping to
take advantage of the more active community and compressed instruction set
support.</li>
<li>PULP is a simple 4-stage design supporting RV32IC as well as the mul
instruction from the M extension.</li>
<li>Synthesising for UMC65, they see 22kilo-gate equivalent per core</li>
<li>The OR10N core was a new OpenRISC implementation with support for hardware
loops, pre/postincrement memory access and vector instructions.</li>
<li>Heading for a GlobalFoundries 28nm tapeout in Q4 2015</li>
<li>See more on PULP <a href="http://iis-projects.ee.ethz.ch/index.php/PULP">at the
website</a>.</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>Second RISC-V Workshop: Day One</title><link>https://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-one/</link><guid>https://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-day-one/</guid><pubDate>Mon, 29 Jun 2015 17:02:57 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ 

<p>The <a href="https://riscv.org/2015/06/preliminary-agenda-for-the-2nd-risc-v-workshop-is-posted/">second RISC-V workshop</a> is going
on today and tomorrow in Berkeley, California. I&rsquo;ll be keeping a semi-live
blog of talks and announcements throughout the day.</p>

<h2 id="introductions-and-welcome-krste-asanović:f089e2b5246d78036f5641020e13d231">Introductions and welcome: Krste Asanović</h2>

<ul>
<li>The beginning of Krste&rsquo;s talk will be familiar for anyone who&rsquo;s seen an
introduction to RISC-V before. Pleasingly, there are a lot of new faces here
at the workshop so the introduction of course makes a lot of sense.</li>
<li>Although the core RISC-V effort is focused on the ISA specification, there
is interest in looking to expand this to look at how to standardise access to
I/O etc.</li>
<li>RV32E is a &ldquo;pre-emptive strike&rdquo; at those who might be tempted to fragment
the ISA space for very small cores. It is a 16-register subset of RV32I.</li>
<li>The compressed instruction set has been released since the last workshop,
there will be talk later today about it. It gives 25-30% code size reduction,
and surprisingly there&rsquo;s still lots of 16-bit encode space for additional
extensions.</li>
<li>Krste makes the point that AArch64 has 8 addressing modes vs just 1 for
RISC-V. The comparison of the size of the GCC/LLVM backends is perhaps less
interesting given that the ARM backend actually has rather a lot more
optimisations.</li>
<li>&ldquo;Simplicity breeds contempt&rdquo;. &ldquo;So far, no evidence more complex ISA is
justified for general code&rdquo;</li>
<li>Will be talking about a Cray-style vector ISA extension later today (i.e.<br />
not packed-SIMD ISA or GPU-style).</li>
<li>Rocket core is only about ~12kloc of Chisel in total. ~5kloc for the
processor, ~2kloc for floating-point units, ~4.6kloc for &lsquo;uncore&rsquo; (coherence
hubs, L2, caches etc).</li>
<li>State of the RISC-V Nation: many companies &lsquo;kicking the tires&rsquo;. If you were
thinking of designing your own RISC ISA for project, then use RISC-V. If you
need a complete working support core <em>today</em> then pay $M for an industry core.<br />
If you need it in 6 months, then consider spending that $M on RISC-V
development.</li>
<li>RISC-V Foundation is being formed, a 501&copy;(6), with Rick O&rsquo;Conner as
Executive Director. The mission statement is &ldquo;to standardize, protect, and
promote the free and open RISC-V instruction set architecture and its hardware
and software ecosystem for use in all computing devices&rdquo;. Plan is to publicly
announce before HotChips later this year and is actively recruiting companies
who want to be &lsquo;founding&rsquo; members. You will need to be a member of the
foundation in good standing to use the RISC-V trademark (unless you are a
non-profit).</li>
</ul>

<h2 id="an-update-on-lowrisc-alex-bradbury:f089e2b5246d78036f5641020e13d231">An update on lowRISC: Alex Bradbury</h2>

<ul>
<li>Many thanks to the audience for all the questions. My slides are <a href="https://speakerdeck.com/asb/an-update-on-lowrisc">available
here</a>.</li>
<li>Unfortunately the SHAKTI project team from India have been caught up in the
malfunctioning US State Department computer systems and so haven&rsquo;t been able
to get visas to give their talk</li>
</ul>

<h2 id="compressed-extension-proposal-david-patterson:f089e2b5246d78036f5641020e13d231">Compressed Extension Proposal: David Patterson</h2>

<ul>
<li>Looked at existing compressed instruction sets, and tried to simplify things
and throw away ideas that add complexity but provide little benefit.</li>
<li>Ended up with a specification that is pleasingly minimal, with each
instruction decoding to a single RV32 instruction.</li>
<li>Keen on community feedback on additional RVC instructions. Identified a set
of 24 that have little impact on current compiler-generated code, but could be
useful for some use cases.</li>
<li>You can read the RVC spec
<a href="https://riscv.org/specifications/compressed-isa/">here</a>.</li>
<li>Points out that Thumb2 is only a 32-bit address ISA. Although it is slightly
smaller than RV32C, the RISC-V compressed spec has the benefit of supporting
64-bit addressing.</li>
<li>Rather than adding the complexity of load multiple and store multiple,
experimented with adding calls to a function that does the same thing. This
hurts performance, but gives a large benefit for code size.</li>
<li>One question was on the power consumption impact. Don&rsquo;t have numbers on that<br />
yet.</li>
<li>Should we require the compressed instruction set? Don&rsquo;t want to add it to
the minimal &lsquo;I&rsquo; instruction set, but could add it to the standard expected by
Linux.</li>
</ul>

<h2 id="goblincore64-a-risc-v-extension-for-data-intensive-computing-john-leidel:f089e2b5246d78036f5641020e13d231">GoblinCore64. A RISC-V Extension for Data Intensive Computing: John Leidel</h2>

<ul>
<li>Building a processor design aimed at data intensive algorithms and
applications. Applications tend to be very cache unfriendly.</li>
<li>GC64 (Goblin Core) has a thread control unit. A very small micro-coded unit
(e.g. implement RV64C) is microcoded to perform the contest switching task.</li>
<li>Have added user-visible registers for thread id, thread context, task
exception register etc etc.</li>
<li>The GKEY supervisor register contains a 64-bit key loaded by the kernel. It
determines whether a task may spawn and execute work on neighboring task
processors, providing a very rudimentary protection mechanism.</li>
<li>Making use of RV128I - it&rsquo;s not just there for fun!</li>
<li>Support various instruction extensions, e.g. IWAIT, SWPAWN, JOIN, GETTASK,
SETTASK. Basic operations needed to write a thread management system (such as
pthreads) implemented as microcoded instructions in the RISC-V ISA.</li>
<li>Also attempting to define the data structures which contain task queue data.</li>
<li>Currently looking at lowRISC-style minion cores to implement microcoded
memory coalescing units.</li>
<li>Read the GC64 specification doc
<a href="http://discl.cs.ttu.edu/gitlab/gc64/gc64-doc/tree/master">here</a>.</li>
</ul>

<h2 id="vector-extension-proposal-krste-asanović:f089e2b5246d78036f5641020e13d231">Vector Extension Proposal: Krste Asanović</h2>

<ul>
<li>Goals: efficient and scalable to all reasonable design points. Be a good
compiler target, and to support implicit auto-vectorisation through OpenMP and
explicit SPMD (OpenCL) programming models. Want to work with virtualisation
layers, and fit into the standard 32-bit encoding space.</li>
<li>Krste is critical of GPUs for general compute. I can summarise his arguments
here, but the slides will be well worth a read. Krste has spent decades
working on vector machines.</li>
<li>With packed SIMD you tend to need completely new instructions for wider
SIMD. Traditional vector machines allow you to set the vector length register
to provide a more uniform programming model. This makes loop strip-mining more
straight-forward.</li>
<li>Add up to 32 vector data registers (v0-v31) in addition to the basic scalar
x and f registers. Each vector register is at least 3 elements each, with
variable bits per element. Also add 8 vector predicate registers, with 1-bit
per element. Finally, add vector configuration and vector length CSR
registers.</li>
<li>Other features

<ul>
<li>Reconfigurable vector registers allow you to exchange unused architectural
registers for longer vectors. e.g. if you only need 4 architectural vector
registers you&rsquo;ll have a larger vector length.</li>
<li>Mixed-precision support</li>
<li>Intenger, fixed-point, floating-point arithmetic</li>
<li>Unit-stride, strided, indexed load/stores</li>
<li>Predication</li>
</ul></li>
<li>Mixed-precision support allows you to subdivide a physical register into
multiple narrower architectural registers as requested.</li>
<li>Sam binary code works regardless of number of physical register bits and the
number of physical lanes.</li>
<li>Use a polymorphic instruction encoding. e.g. a single signed integer ADD
opcode that works on different size inputs and outputs.</li>
<li>Have separate integer and floating-point loads and stores, where the size is
inherent in the destination register number.</li>
<li>All instructions are implicitly predicated under the first predicate
register by default.</li>
<li>What is the difference between V and Hwacha? Hwacha is a non-standard
Berkeley vector extensions design to push the state-of-the-art for
in-order/decoupled vector machines. There are similarities in the lane
microarchitecture. Current focus is bringing up OpenCL for Hwacha, with the V
extension to follow.</li>
<li>Restartable page faults are supported. Similar to the DEC Vector VAX.</li>
<li>Krste pleads people not to implement a packed SIMD extension, pointing out
that a minimal V implementation would be very space efficient.</li>
</ul>

<h2 id="privileged-architecture-proposal-andrew-waterman:f089e2b5246d78036f5641020e13d231">Privileged Architecture Proposal: Andrew Waterman</h2>

<ul>
<li>Aims to provide a clean split between layers of the stack.</li>
<li>You can read the privileged spec
<a href="https://riscv.org/specifications/privileged-isa/">here</a>.</li>
<li>Supports four privilege modes. User, Supervisor, Hypervisor and Machine
mode.</li>
<li>For a simple embedded system that only needs M-mode there is a low
implementation cost. Only 2^7 bits of architectural state in addition to the
user ISA, plus 2^7 more bits for timers and another 2^7 for basic performance
counters.</li>
<li>Defined the basic virtual memory architectures to support current Unix-style
operating systems. The design is fairly conventional, using 4KiB pages.</li>
<li>Why go with 4KiB pages rather than 8KiB as was the initial plan? Concerned
with porting software hard-coded to expect 4KiB pages. Also concerns about
internal fragmentation.</li>
<li>Physical memory attributes such as cacheability are not encoded in the page
table in RISC-V. Two major reasons that Andrew disagrees with this are that
the granularity may not be tied to the page size, plus it is problematic for
virtualisation. Potentially coherent DMA will become more common meaning you
needn&rsquo;t worry about these attributes.</li>
<li>Want to support device interactions via a virtio-style interface.</li>
<li>The draft Supervisor Binary Interface will be released with the next
privileged ISA draft. It includes common functionality for TLB shootdowns,
reboot/shutdown, sending inter-processor interrupts etc etc. This is a similar
idea to the PALCode on the Alpha.</li>
<li>Hardware-accelerated virtualization (H-mode) is planned, but not yet
specified.</li>
<li>A draft version of v1.8 of the spec is expected this summer, with a frozen
v2.0 targeted for the fall.</li>
</ul>

<h2 id="rapidio-the-unified-fabric-for-performance-critical-computing-rick-o-connor:f089e2b5246d78036f5641020e13d231">RapidIO. The Unified Fabric for Performance-Critical Computing: Rick O&rsquo;Connor</h2>

<ul>
<li>There are more 10Gbps RapidIO ports on the planet than there are 10Gbps
Ethernet ports. This is primarily due to the 100% market penetration in 4G/LTE
and 60% global 3G.</li>
<li>The IIT Madras team are using RapidIO extensively for their RISC-V work</li>
<li>Has been doing work in the data center and HPC space. Looking to use the AXI
ACE and connect that to RapidIO.</li>
<li>There is interesting work on an open source RapidIO stack.</li>
</ul>

<h2 id="cava-cluster-in-a-rack-peter-hsu:f089e2b5246d78036f5641020e13d231">CAVA. Cluster in a rack: Peter Hsu</h2>

<ul>
<li>Problem: designing a new computer is expensive. But 80% is the same every
time.</li>
<li>CAVA is not the same as the Oracle RAPID project.</li>
<li>Would like to build a 1024-node cluster in a rack. DDR4 3200 = 25.6GB/s per
64-bit channel. Each 1U card would be about 600W with 32 nodes.</li>
<li>Looking at a 96-core 10nm chip (scaled from a previous 350nm project).<br />
Suppose you have a 3-issue out of order core (600K gates) and 32KiB I+d cache,
that would be around 0.24mm^2 in 10nm.</li>
<li>Estimate a vector unit might be around the same area.</li>
<li>Peter has detailed estimates for per-chip power, but it&rsquo;s probably best to
refer to the slides for these.</li>
<li>Research plan for the cluster involves a unified simulation environment,
running on generic clusters of x86 using open-source software. Everyone uses
the same simulator to perform &ldquo;apples to apples&rdquo; comparison. This allows easy
replication of published work.</li>
<li>Simulation infrastructure will involve a pipeline siumlator, SoC simulator
(uncore logic), and a network simulator.</li>
<li>Interested in applying Cray-style vectors to database workloads</li>
<li>Could also have the ability to make associativity ways and possible
individual cache lines lockable.</li>
</ul>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>Summer of Code students for lowRISC</title><link>https://www.lowrisc.org/blog/2015/05/summer-of-code-students-for-lowrisc/</link><guid>https://www.lowrisc.org/blog/2015/05/summer-of-code-students-for-lowrisc/</guid><pubDate>Wed, 13 May 2015 20:45:07 +0100</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>lowRISC was fortunate enough to be chosen as a mentoring organisation in this
year&rsquo;s <a href="https://developers.google.com/open-source/soc/">Google Summer of
Code</a>. The Google Summer of
Code program funds students to work on open source projects over the summer.
We had 52 applications across the <a href="https://www.lowrisc.org/docs/gsoc-2015-ideas/">range of project
ideas</a> we&rsquo;ve been advertising.
As you can see from the range of project ideas, lowRISC is taking part as an
umbrella organisation, working with a number of our friends in the wider open
source software and hardware community.
We were allocated three slots from Google, and given the volume of high
quality applications making the selection was tremendously difficult. We have
actually been able to fund an additional three applicants from other sources,
but even then there were many promising projects we couldn&rsquo;t support. We are
extremely grateful to all the students who put so much time and effort in to
their proposals, and to everyone who volunteered to mentor. The six &lsquo;summer of
code&rsquo; projects for lowRISC are:</p>

<ul>
<li><p><a href="http://www.google-melange.com/gsoc/project/details/google/gsoc2015/asy/5757334940811264">An online Verilog IDE based on
YosysJS</a>.
Baptiste Duprat mentored by Clifford Wolf</p>

<ul>
<li>Baptiste will be working with an Emscripten-compiled version of
the <a href="http://www.clifford.at/yosys/">Yosys</a> logic synthesis tool, building an
online Verilog IDE on top
of it which would be particularly suitable for training and teaching
materials. A big chunk of the proposed work is related to visualisation of the
generated logic. Improving the accessibility of hardware design is essential for
growing the potential contributor base to open source hardware
projects like lowRISC, and this is just the start of our efforts in that
space.</li>
</ul></li>

<li><p><a href="http://www.google-melange.com/gsoc/project/details/google/gsoc2015/hesham/5868011953061888">Porting seL4 to
RISC-V</a>.
Hesham ALMatary mentored by Stefan Wallentowitz</p>

<ul>
<li><a href="https://sel4.systems/">seL4</a> is a formally verified microkernel, which
currently has ports
for x86 and ARM. Hesham will be performing a complete port to
RISC-V/lowRISC. Security and microkernels are of great interest to
many in the community. It&rsquo;s also a good opportunity to expand RISC-V platform
support and to put the recently released <a href="https://blog.riscv.org/2015/05/risc-v-draft-privileged-architecture-version-1-7-released/">RISC-V Privileged Architecture
Specification</a>
through its paces. Hesham previously performed a port of RTEMS to
OpenRISC.</li>
</ul></li>

<li><p><a href="http://www.google-melange.com/gsoc/project/details/google/gsoc2015/prannoy1994/5651442522128384">Porting jor1k to
RISC-V</a>.
Prannoy Pilligundla mentored by Sebastian Macke</p>

<ul>
<li><a href="https://s-macke.github.io/jor1k/">jor1k</a> is by far the
<a href="https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-emulators">fastest</a>
Javascript-based full system
simulator. It also features a network device, filesystem support, and
a framebuffer. Prannoy will be adding support for RISC-V and look at
supporting some of the features we offer on lowRISC such as <a href="https://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-minion-cores/">minion
cores or tagged
memory</a>.
This will be great not only as a demo, but
also have practical uses in tutorial or educational material.</li>
</ul></li>

<li><p>TCP offload to minion cores using rump kernels. Sebastian Wicki
mentored by Justin Cormack</p>

<ul>
<li>The intention here is to get a <a href="http://rumpkernel.org/">rump kernel</a>
(essentially a libified
NetBSD) running bare-metal on a simple RISC-V system and evaluate
exposing the TCP/IP stack for use by other cores. e.g. a TCP/IP
offload engine running on a minion core. TCP offload is a good
starting point, but of course the same concept could be applied
elsewhere. For example, running a USB mass storage driver (and filesystem
implementation) on a minion core and providing a simple high-level
interface to the application cores.</li>
</ul></li>

<li><p>Extend Tavor to support directed generation of assembly test cases.
Yoann Blein mentored by Markus Zimmermann</p>

<ul>
<li><a href="https://github.com/zimmski/tavor">Tavor</a> is a sophisticated fuzzing tool
implemented in Go. Yoann
will be extending it to more readily support specifying instruction
set features and generating a fuzzing suite targeting an ISA such as
RISC-V. Yoann has some really interesting ideas on how to go about
this, so I&rsquo;m really interested in seeing where this on ends up.</li>
</ul></li>

<li><p>Implement a Wishbone to TileLink bridge and extend TileLink
documentation. Thomas Repetti mentored by Wei Song</p>

<ul>
<li><a href="http://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29">Wishbone</a> is the
interconnect of choice for most existing open
source IP cores, including most devices on
<a href="http://opencores.org/">opencores.org</a>. The Berkeley
<a href="https://github.com/ucb-bar/rocket-chip">Rocket</a> RISC-V implementation uses
their own &lsquo;TileLink&rsquo; protocol (we provide a <a href="https://www.lowrisc.org/docs/tagged-memory-v0.1/rocket-chip/">brief
overview</a>. By providing a
reusable bridge, this project will allow the easy reuse of opencores devices
and leverage the many man-years of effort that has already gone in to them.</li>
</ul></li>
</ul>

<p>The first 3 of the above projects are part of Google Summer of Code
and the bottom 3 directly funded, operating over roughly the same timeline.
We&rsquo;re also going to be having two local
students interning with us here at the University of Cambridge
Computer Lab starting towards the end of June, so it&rsquo;s going to be a
busy and productive summer. It bears repeating just how much we appreciate the
support of everyone involved so far - Google through their Summer of Code
initiative, the students, and those who&rsquo;ve offered to act as mentors. We&rsquo;re
very excited about these projects, so please join us in welcoming the students
involved to our community. If you have any questions, suggestions, or guidance
please do leave them in the comments.</p>

<p><em>Alex Bradbury</em></p>
 ]]></description></item><item><title>lowRISC tagged memory preview release</title><link>https://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/</link><guid>https://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/</guid><pubDate>Mon, 13 Apr 2015 22:28:10 +0000</pubDate><author>info@lowrisc.org (lowRISC)</author><description><![CDATA[ <p>We&rsquo;re pleased to announce the <a href="https://www.lowrisc.org/docs/tagged-memory-v0.1/">first lowRISC preview release</a>, demonstrating support for tagged memory as
described in <a href="https://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-minion-cores/">our memo</a>. Our ambition with lowRISC is to provide an open-source System-on-Chip
platform for others to build on, along with low-cost development boards
featuring a reference implementation. Although there&rsquo;s more work to be done on
the tagged memory implementation, now seemed a good time to document what
we&rsquo;ve done in order for the wider community to take a look. Please see our
<a href="https://www.lowrisc.org/docs/tagged-memory-v0.1/">full tutorial</a> which describes in some
detail the changes we&rsquo;ve made to the Berkeley <a href="https://github.com/ucb-bar/rocket">Rocket
core</a>, as well as how you can build and try
it out for yourself (either in simulation, or on an FPGA). We&rsquo;ve gone to some
effort to produce this documentation, both to document our work, and to share
our experiences building upon the Berkeley RISC-V code releases in the hopes
they&rsquo;ll be useful to other groups.</p>

<p>The initial motivation for tagged memory was to prevent control-flow hijacking
attacks, though there are a range of other potential uses including
fine-grained memory synchronisation, garbage collection, and debug tools.<br />
Please note that the instructions used to manipulate tagged memory in this
release (<code>ltag</code> and <code>stag</code>) are only temporary and chosen simply because they
require minimal changes to the core pipeline. Future work will include
exploring better ISA support, collecting performance numbers across a range of
tagged memory uses and tuning the tag cache. We are also working on developing
an &lsquo;untethered&rsquo; version of the SoC with the necessary peripherals integrated
for standalone operation.</p>

<p>If you&rsquo;ve visited lowrisc.org before, you&rsquo;ll have noticed we&rsquo;ve changed a few
things around. Keep an eye on this blog (and its <a href="https://www.lowrisc.org/index.xml">RSS
feed</a>) to keep an eye on developments - we
expect to be updating at least every couple of weeks. We&rsquo;re very grateful to
the RISC-V team at Berkeley for all their support and guidance. A large
portion of the credit for this initial code release goes to <a href="http://wsong83.github.io/">Wei
Song</a>, who&rsquo;s been working tirelessly on the HDL
implementation.</p>
 ]]></description></item></channel></rss>