Close

Open Source Chip Design Hack Chat Transcript

A event log for Open Source Chip Design Hack Chat

Join us in a discussion with SiFive about custom silicon and RISC-V

shulie-tornelShulie Tornel 04/14/2017 at 19:570 Comments

Jack Kang Sure, hi everybody! My name is Jack and I am VP of Product and Business Development at SiFive. before SiFive, I started my career as a front end chip designer, working on bus controllers, memory controllers, and CPUs. then moved into product marketing/management/BD etc at large chip companies, both Marvell and NVIDIA. SiFive was founded by the inventors of RISC-V, and our mission is to make custom silicon available to all

Jack Kang Our chips are all based on the free and open RISC-V ISA, and we launched our first chip, the FE310 last November, which itself is also open sourced

Sophi Kravitz Can you walk us through the "getting a chip made" process

Jack Kang it's a very long and expensive process that's getting longer and more expensive! at least, that's the direction it's been heading at most chip companies. back in the old days, when Moore's law was humming along, everybody would just rush to go to the next node ASAP--because things would just be cheaper and faster. so the methodology of many of the traditional chip companies have been built around that idea. at the simplest level, you have a front end team that's focused on the RTL/digital portion of the design, which would then pass it off to the backend team, which would work on the physical design/synthesis/etc., then pass it along to foundries to actually manufacture. the front end team and back end teams work independently, and the number of folks required has grown as these chips have grown in complexity. so the entire design cycle these days from defining a chip, going through the front end + back end plus manufacturing is easily 18+ months for the advanced process nodes. sorry, your question was pretty broad so not sure where you'd like me to focus down a bit more on :)

Sophi Kravitz what is an advanced process node? (that was a good explanation thanks!)

Jack Kang the nodes refer to the size of the transistor...so in recent years we've gone from 40nm process to 28nm to 16nm (or 14nm)

Jack Kang there was a big jump once we went to 16nm and below because we now use FINFET transistors

Jack Kang some people also call those 3D transistors

Sophi Kravitz ooooo what are those?

Jack Kang so these days an advanced node is probably a finfet node of lower (16nm/14nm, 10nm, 7nm)

Piotr Esden-Tempski Which node is SiFive concentrating on. I assume you are not going all the way to the most modern nodes due to cost?

Jack Kang the transistor is basically a switch, with a gate in the middle. We used to lay these down flat. with a finfet, the gate stands up (kind of like a shark fin, which is why it's called FINFET) they flip it. SiFive is focused on two nodes at the moment: 180nm and 28n. the 180nm is for our microcontroller/IOT type low cost platform. 28nm is still a very advanced node that allows for high performance CPU, PCIe Gen3, DDR4 @ 2400 MT/s.

Lars R. With more and more Opensource tools becoming available, are you going to enter into Opensource FPGA development? You could even add the Risc-V as a hard macro.

Jack Kang I think and opensource FPGA and FPGA tool flow would be great for the ecosystem as whole!! but for now, we have to be content with people using open source RTL and mapping it down to the FPGAs. a hard macro RISC-V inside a FPGA...would be a great accomplishment for RISC-V.

Karim Yaghmour What tools do you use to synthesize your chips? And do you do this in-house or do you outsource that?

Jack Kang i guess i'll just say there are multiple FPGA companies as part of the RISC-V foundation and leave it at that ;)

Matt D. I'm curious, have you been using some of the formal verification tools at SiFive, e.g., Yosys-SMTBMC?

Jack Kang We use commercial tools from the EDA vendors, and we do that inside of SiFive. Formal verification is a big part of what we do. A major area of focus for us is to be able to customize silicon for customers. when you customize, you want to be able to verify that the customizations don't introduce any bugs or unforseen side effect. leveraging formal verification allows us to do a lot of that.

JulienYou already launched 180nm based microcontroller, what is your timeline for 28nm microprocessor?

Lars R.Yes, but the motivation for an Opensource FPGA is another one. And the companies in the RISC-V foundation are against an OpenSource FPGA for sure. So you are already limited/bound to such a huge extent...

Jack Kang oh--on the FPGA question--one thing I can say publicly is that you can access RTL for a SiFive RISC-V core within the Microsemi toolchain already today for their FPGAs

Lars R. Yes

Matt D. Thank you for tne answer! Interesting! What has been your experience so far -- any major pain points, things to be aware of? How much is it possible to rely on automation with respect to specification verification (as in: using SMT solvers solely verifying the properties -- as opposed to manually handcrafted cases in testbenches)

Jack Kang @Julien we are working very hard to tapeout the 28nm Freedom Unleashed platform ASAP ...we don't have an exact date yet but it'll be soon! (this year)

Jack Kang we know the ecosystem needs it to do major software development like Linux

Jack Kang @Matt D. we are building formal verification as a key part of our flow, to the extent that our front end designers need to be fully bought in and be designing their portions with assertions in mind.

Julien Nice, I'm sure such a platform will attract a lot of open source software contributors !

Jack Kang our intention is to rely on automation as much as possible, and for the areas where automation can't be done--figure out why it can't be automated and work on how it can be

Jack Kang @Julien yes! and the software development community is what makes RISC-V so amazing!

Matt D. @Jack Kang Thank you for the answer, sounds encouraging!

Jack Kang even in our microcontroller platform i've been amazed to see new OS and other SW ports showing up every week, through open source

Julien If I understood your business model, you offer service around your core IP, do you already have customers working with you on new SOCs or microcontrollers ?

Piotr Esden-Tempski @Jack Kang are you guys involved at all with things like llvm support for the RISC-V ... this is one of the things that is preventing modern languages like Rust being supported. Or are you leaving that to the community and concentrating on the lower level part of the system?

Jack Kang like Zephyr OS, FreeRTOS, and most recently somebody has been working on porting Forth, just to name a few

Jack Kang on the business side, we have 2 areas of focus

Jack Kang the first is core IP licensing--in this area chip companies work with us to license RISC-V cores to put into their chip. this one is interesting because there are open source RTL of RISC-V cores, but many of these companies prefer to work with us because they want some sort of customization and/or support, verification etc.

Jack Kang so those companies are building their own SOCs and microcontroller. the second part of business is helping folks build custom silicon. here, we work with system companies or product companies. We customize based on our base platform and sell chips to these guys.

Jordi OrlandoDo you have any updated plans or timeline for selling bare chips (without dev boards)?

Jack Kang the FE310, which is available, is an example of our microcontroller based platform. folks may then come along and say, hey, my application looks a lot like that, but can you add maybe a LDO or a bigger SRAM, or some custom instruction, etc. then we will do that and sell them the chip.

Jack Kang @Piotr Esden-Tempski for LLVM specifically, there are a bunch of folks in the RISC-V community already working on that. We contribute heavily to the SW and tools. GCC, for example, which has just been accepted for upstreaming was the work of many folks here at SiFive (along with lots of others in the community)

Jack Kang SiFive is going to be one of the maintainers of the GCC port still

Jack Kang @Jordi Orlando yes, this is one of the most common questions that I get!

Julien Very nice, can't wait to see a rising hardware ecosystem based on RISC-V

Jack Kang we will make it available...but there are issues we have to work through before we can sell the chip. But that is definitely our intention

Jack Kang if you just need some units for samples or a special project, you can email us at info@sifive.com and we can try to help

Jack Kang but general selling/availability will take some more time

Jordi Orlando @Jack Kang that's great to hear, thank you!

Jack Kang @Piotr Esden-Tempski https://github.com/lowrisc/riscv-llvm is a link to the LLVM project

Lars R. Interesting, thx!

Jack Kang you can also see lots of other RISC-V SW projects here: https://github.com/riscv/riscv-wiki/wiki/RISC-V-Software-Status

Jack Kang actually https://github.com/riscv/riscv-llvm might be more recent....

Piotr Esden-Tempski @Jack Kang Yes thank you for the link. I am aware that LLVM is in the works, I was only curious if you are also involved. Can't wait to see Rust have RISC-V target that is all. :)

Piotr Esden-TempskiThe LLVM team is mentioning RISC-V as the platform to emulate on how to add new support, they were very happy so far, there are still a few patches pending.

Jack Kang @Lutetium should i tackle some of the google doc questions?

Max PoppDid I understand that correct that it with SiFive it is possible to design a custom chip as a normal person?

Jack Kang we can enable you to design with us. We would be able to take your specs and do the design for you, and sell you the chip directly. you don't need to know about chip design. the main difference is because of our automation and flow, we can do this at much lower cost and barrier to entry. which means we are open to talking to a "normal person". you don't need to be a big company with many millions of dollars for us to talk to you :) Unlike how it's like at the traditional chip companies these days.

Shulie TornelNathan: "How does RISC-V compare to other cores such as ARM Cortex M1 or MicroBlaze on an (Xilinx Artix-7 or Kintex-7) FPGA in terms of computational performance, power consumption, and resource utilization (equivalent gates / LUTs)?"

Max Popp Could You give me a prize example please? Let's say for a U500 based chip.

Lars R. ...or could you in general be more specific in what markets/customers you are targeting?

Jack Kang for example, for our microcontroller platform (Freedom Everywhere), we can build a custom chip for around $100K NRE--it's still $100K but it's very achievable with a kickstarter campaign, etc. We want to keep driving that down but that's what we mean by making it accesible to all

Jack Kang For Freedom Everywhere, which is our 180nm platform, that is targeted for Microcontrollers, Embedded, and IOT. in that platform, we have our E3 series of CPUs today. it's important to note that RISC-V is the ISA spec, so you can many types of CPU implementations (high performance, small, low power, etc. etc.) our E3 implementations are 32-bit embedded cores, and are closer to the Cortex-M family from ARM. if you look at the FE310 chip, we have the E31 CPU. That CPU is 320MHz, and has a DMIPS/MHz of 1.61. compare that to a M3 or M4, which tend to be around 100MHz or so, with a DMIPS/MHz of ~1 ish.

Max Popp Are U500 based chips able to run for example Android?

Jack Kang compare that to a M3 or M4, which tend to be around 100MHz or so, with a DMIPS/MHz of ~1 ish. we also see benefits in power, where the DMIPS/mW of our cores are almost 2x ARM's in the same process node. our Freedom Unleashed platform, bulit in 28nm, is targeted for datacenter accelerators, storage controllers, networking, machine learning applications in the datacenter

Jack Kang those feature our U5 series coreplex, which are 64-bit, multicore processors that are more like the Cortex-A familiy in performance

Jack Kang @Max Popp Running Android well is a system question. in the case of our Freedom Unleashed, we do not have a embedded GPU in that platform right now

Carol Willing What do you think is the minimum configuration for Freedom Unleashed platform for machine learning applications (boards, dev kit, etc)?

Jack Kang so your android performance would be poor because a lot of Android depends/requires GPU for the GUI. If you run it GUI-less---well then you're basically in a Linux/Unix type environment and the Unleashed platforms run those really well

Sophi Kravitz HI @Carol Willing !

Garret Kelly Any plans for a SiFive GPU? :)

Sophi Kravitz Also- this chat is over time- you good to stay for a bit @Jack Kang ?

Carol Willing Hi @Sophi Kravitz. Will be in NYC next wk.

Lars R. 100K USD is for the "whole package" including support, not just the manufacturing cost. I give you RTL and I get the chup?

Matt D. @Jack Kang Can I ask a broader question on the industry evolution? If so, I'm curious about your thoughts on the recent trend of marrying FPGAs and CPUs -- whether embedded (eFPGAs, like Achronix or Flex Logix) or on-package integration, like the Intel's Xeon+FPGA. Is this something that may become more widespread in the future, for general purpose commodity CPUs, or is reconfigurability mostly going to remain confined to (relatively) special-purpose use cases instead?

Carol Willing Thurs-Monday.

Jack Kang i think for machine learning applications--this is such a rapidly developing field that we think there are going to be ne ways for people to program those devices. For RISC-V, we are working on a standard RISC-V Vector extension

Frank Buss could you implement the E3 in 28 nm and would that then be ultra low-power or something?

Jack Kang we think the Vector extension will allow for much better performance/power but still be programmable rather than a fixed function design

Jack Kang @Sophi Kravitz yes i can stay for a bit longer :)

Sophi Kravitz :) excellent

Jack Kang @Lars R. Yes, basically. We would have a per chip cost that depends on the chip itself also

Yann Guidon / YGD Good because I only arrived :-D

Lars R. This sounds great.

Jack Kang @Frank Buss Yes, exactly. We have customers who license our IP and implement it in all sorts of different nodes

Max Popp Are You planning to implement a GPU in the "high end" chips? That would be great

Jack Kang @Matt D. i think the reason for this broader trend of FPGA + CPU is because the fundamental compute requirements are evolving rapidly

Jørgen Kragh Jakobsen Hi Jack : How big is your team ?

Jack Kang people want to compute different workloads and they don't know exactly what type of workload it is

Jack Kang and since it's so expensive and time consuming to develop new chips (as we discussed earlier), CPUs + FPGAs are looked at as one way to solve it

Jack Kang but if you can provide great performance with programmability (which is what a CPU is...and why people started with using GPUs for Machine Learning)--and i think Vector extensions allow that for RISC-V

Jack Kang if you can provide that great performance + have the ability to quickly develop new silicon with some custom logic, then I think you can really win

Jack Kang and that's where SiFive is going, at least with our higher end platforms

Jack Kang @Max Popp that still remains to be seen. In the current markets of focus a GPU is not really required

Matt D. @Jack Kang Thanks! Tracking the vector extension with interest, too! I recall the Hwacha project having some pretty interesting publications.

Jack Kang well we have Yunsup (who did Hwacha) as one of the co-founders of SiFive, along with Krste (professor at UC Berkeley) who did his PhD way back in the day on using vectors for neural net processing

Jack Kang so it's certainly something we think we have lots of great experience in

Matt D. :-)

Yann Guidon / YGDES But vector code needs even more memory bandwidth :-)

Matt D. I didn't know Krste worked on that in his PhD, that's pretty cool :-)

Jack Kang more memory bandwidth is always better :)

Jack Kang I think there was a chisel question from the google docs: Chisel is used for the reference implementation of RISC-V. What are the benefits of Chisel over a traditional RTL HDL such as VHDL or Verilog?

Shulie Tornel running transcript: https://hackaday.io/event/21084-open-source-chip-design-hack-chat/log/57313-open-source-chip-design-hack-chat-transcript

Jack Kang we like chisel because it's modern, and allows for us to capture the design in a much smaller code size, which simply allows for much better productivity

Yann Guidon / YGDES Thank you Shulie

Benjamin Vernoux Do you have more details about the U500 ?

Jack Kang it also allows for significant easier design re-use

Max Popp Okay thanks. I heard about a classic game console that uses an FPGA instead of a GPU. Would it be possible to do that with a U500 too?

Jack Kang the comparison between Chisel and Verilog to us is the difference between programming in a high level language vs programming directly in assembly

Jack Kang Our Chisel actually generates a verilog that we then feed into the standard EDA tools

Yann Guidon / YGDES VHDL can do pretty high level design :-D

Carol Willing Nice!

Jack Kang @Benjamin Vernoux we have a product brief for the U500 here: https://dev.sifive.com/documentation/freedom-u500-platform-brief

Frank Bus in VHDL you have generate statements and even procedures and functions, which are synthesized

Jack Kang multicore, 64-bit, with L2 caches. high speed peripherals: PCIe Gen3, DDR4, GbE

Nathan Kohagen Is there a formal analysis tool for comparing Chisel to the generated Verilog?

Jack Kang if you like using high level design for hardware you will really enjoy Chisel :)

Carol Willing Chisel looks cool and in Scala.

Matt D. @Jack Kang How well does Chisel integrate with the rest of the toolchain(s) -- e.g., if you need to tweak something to meet timing closure, is it necessary to manipulate the generated Verilog (or have parts of the design in Verilog), or do you think issues are generally still solvable on the Chisel side in practice?

Benjamin Vernoux Do you have more details on different packages which will be available ? (a Must will be to have ultra small package with 100pins ...) and When they are planned ?

Frank Buss what can Chisel what VHDL can't do? I really like generic map in VHDL, so e.g. you can specifiy the address bus witdth as one constant

Matt D. @Jack Kang (Clarification: I meant "do you find".)

Jack Kang we generate verilog from our chisel then run that through the flow--if changes need to be made to the design we go back and do it in chisel then regernate verilog. Anything you can do in verilog you can do in chisel. Just like you can do asm in C if you really wanted to

Frank Buss is it this: https://chisel.eecs.berkeley.edu/ ? it is written in Scala, I did a course in this language some time ago, sorry for asking, this is obviously much more powerful :-)

Jack Kang @Frank Buss Chisel is based on Scala, so it's a full featured programming langauge

Frank Buss thanks, I will try it

Matt D. @Jack Kang Right, thanks! Interesting, will have to look into Chisel (currently mostly preferring SystemVerilog, toolchain integration is one issue I've been wary of, even the SystemVerilog standard support can be somewhat uneven across the toolchains.)

Jack Kang @Benjamin Vernoux we haven't decided on U500 package yet. but yes there will be lots of pins

Jack Kang @Nathan Kohagen we write generators in Chisel, then do our verification in Verilog. So we verify the Verilog RTL

Jack Kang lots of great questions! we went quite a bit over :)

Matt D. :-)

Discussions