WP_Term Object
    [term_id] => 51
    [name] => RISC-V
    [slug] => risc-v
    [term_group] => 0
    [term_taxonomy_id] => 51
    [taxonomy] => category
    [description] => 
    [parent] => 178
    [count] => 44
    [filter] => raw
    [cat_ID] => 51
    [category_count] => 44
    [category_description] => 
    [cat_name] => RISC-V
    [category_nicename] => risc-v
    [category_parent] => 178
    [is_post] => 1

RISC-V Ready (Tools) Set (Security) Go (Build)

RISC-V Ready (Tools) Set (Security) Go (Build)
by Camille Kokozaki on 06-26-2018 at 12:00 pm

The second Bay Area RISC-V Meetup event was held at the DoubleTree Hilton in Burlingame on June 19 with about 150 attendees. This event was hosted by SiFive and started with a networking session. The topics and speakers for the evening were:

  • Commercial Software Tools – Larry Lapides, Imperas
  • Securing RISC-V Processors – Dan Ganousis, Dover Microsystems
  • Extending Unleashed with AI Accelerators – Palmer Dabbelt, SiFive

Larry Lapides from Imperas opened by reasoning why commercial tools are needed even in an open source world when the initial perception is that the open source, free, tools, and software are good enough. In addition, he clarified that even allowing that the community is contributing to the open source tools, those tools offered may not be at the leading edge, highlighting and acknowledging the following situation:

  • Free is always good for the academic community (but many commercial tools companies provide their products for free to universities).
  • Open source is important, for the RISC-V content
  • Open source for the tool itself, separate from the content, is not necessary and may result in sub-optimal tools being used
  • Supporting tools internally means having valuable engineering resources tied up understanding the tools, which does not contribute directly to any value being provided by the company’s products
  • Many open source tools have a GPL source license, which is not business friendly

With clever references to Monty Python’s Holy Grail one-liners (‘Bring out your dead’, ‘It’s Only a Flesh Wound’), Larry provided examples of defunct open source software and scenarios of unending patch releases and workarounds that could have been prevented if a robust commercial software ecosystem was sustaining the open source world. Quick ‘make versus buy’ calculations usually point to a cheaper safer path of buying tools when the total cost of effort and rework is included.

Larry then provided a lay of the land in terms of what commercial tools are out there, emphasizing that many of these companies have an open source aspect of their offerings, and that delivering high quality, supported products remains the primary business objective.

Commercial Software Tools
[table] border=”1″ cellspacing=”0″ cellpadding=”0″ align=”left”
| style=”width: 311px” | Compiler / Toolchain

  • IAR (available soon)

Debug & Trace
Conventional run control, source code debug tools, typically using JTAG connections OR IP-based tools, providing additional analysis including trace and platform-centric tools

  • Ashling
  • Lauterbach
  • Segger
  • UltraSoC

Software simulation

  • Imperas

| style=”width: 311px” | OS

  • RTOS

Amazon FreeRTOS

Apache Mynewt

Express Logic (ThreadX)

Micrium uC/OS


  • Linux


Red Hat-Fedora

Security tools

  • SecureRF


  • Runtime.io


Larry closed by providing an update of Imperas RISC-V status (summarized below, more here):
Processor models

  • RV32/64 GCN, RV32EC
  • Andes N25, NX25 including custom instructions
  • SiFive Mi-V (RV32IMA), E31, E51, U54
  • The solution enables easy addition of custom instructions, registers, etc. to processor model via extension library


Imperas tool support for RISC-V

  • MPD debugger for heterogeneous, multiprocessor/multicore platforms and driver-peripheral co-debug
  • Verification, Analysis and Profiling (VAP) tools including tracing, profiling, code coverage, OS-aware tools,
  • Timing estimation (paper at Embedded World)

In the next session, Dan GanousisfromDover Microsystems provided insight into ways to securing RISC-V Processors and what perceptions there are about the security (or unpleasant surprises when the lack of it is discovered). The impediments to developing secure connected devices can be:

[table] border=”1″ cellspacing=”0″ cellpadding=”0″
| style=”width: 311px” |

  • Security Requirements
  • Lack of standards
  • Simple user setup
  • Too many technical choices

| style=”width: 311px” |

  • Design Complexity
  • Testing/QA Complexity
  • Component cost
  • Time to Market
  • Needing to learn new skills


Many companies believe their products are secure, but few actually are. None of this is more apparent than the IoT world where security now tops (by far) all IoT concerns that include interoperability, connectivity, integration, standards, ROI, Cost, scalability, privacy, performance and many other concerns.

The consequences of a lack of security can be severe with examples of breaches in electric grid causing blackout, hacking from the ground into in-flight airplane control and navigation systems, hacking car instrumentation and control, banking credit card fraud, health monitoring system disruption of medical devices and operations. A sobering statistic from the government states that 90%or security incidents result from ‘exploits against defects in software’.

In order to secure RISC-V processors, the following must occur:

  • Create a security threat model by identifying and prioritizing assets and vulnerabilities followed by defining countermeasures to prevent or mitigate the effects of threats to the system.
  • Design for Security (DFS) because a vulnerability in hardware is a non-patchable problem.
  • Implement a Root of Trust security block for integration into the semiconductor device, offering secure execution of applications, tamper detection, secure storage, key management, authentication and many other security implements. Creating a digital fingerprint called Physically Unclonable Function (PUF) provides unique device identity.
  • Incorporate predesigned Secure IP functions
  • Implement a Sentry Processor

(CoreGuard Diagram from the 8[SUP]th[/SUP] RISC-V Workshop Barcelona Poster Sessions)

In the last session, Palmer Dabbelt from SiFive outlined how designs can be extended with AI accelerators. In addition to companies building their designs on top of Open-Source Technology, SiFive can now be considered as providing a Hardware Technology Stack in terms of Infrastructure but also as a provider of Silicon Cloud Services.

The Silicon Cloud Services (SCS) consist of allowing customers to integrate either low power 32-bit microcontrollers (Freedom Everywhere) or high-performance 64-bit multi-cores (Freedom Unleashed) with 3[SUP]rd[/SUP] party DesignShare IP from Rambus, UltraSOC, flexlogix, eMemory, Analog Bits, ThinkSilicon and/or customer designed IP. The SCS path allows verification to be done in the cloud before actually paying for the IP, shifting the payment at tape-out time with SiFive providing support in the tape-out operations.

HiFive Unleashed was highlighted as the world’s first Multi-Core RISC-V Linux Development Board and a running demo was shown that illustrated training and image recognition.


Palmer closed by inviting individuals or companies to submit proposals for designing one’s own Freedom Chip before Oct 31, 2018. These proposals can include IP blocks, accelerators, co-processors. SiFive will consider partnerships which could involve helping implement a custom CPU IP, along with design support, and help in the operational aspects of tape-out and deliver working samples.

SiFive will announce partners at the First Annual RISC-V Summit to be held Dec 3-5, 2018. Slides of the Meetup can be found here.


One Reply to “RISC-V Ready (Tools) Set (Security) Go (Build)”

You must register or log in to view/post comments.