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
Sophi Kravitz Can you walk us through the "getting a chip made" process
. 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 :)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
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
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)
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.
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.
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.
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?
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.
You already launched 180nm based microcontroller, what is your timeline for 28nm microprocessor?
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...
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
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)
@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)
we know the ecosystem needs it to do major software development like Linux
@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
@Julien yes! and the software development community is what makes RISC-V so amazing!
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
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
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.
Do you have any updated plans or timeline for selling bare chips (without dev boards)?
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.
@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)
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
but general selling/availability will take some more time
Lars R. Interesting, thx!
@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. :)
The 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.
@Lutetium should i tackle some of the google doc questions?
Did I understand that correct that it with SiFive it is possible to design a custom chip as 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.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"
Nathan: "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)?"
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?
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
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.
Are U500 based chips able to run for example Android?
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
@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
Garret Kelly Any plans for a SiFive GPU? :)
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.
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
Sophi Kravitz :) excellent
Yann Guidon / YGD Good because I only arrived :-D
Lars R. This sounds great.
Are You planning to implement a GPU in the "high end" chips? That would be great
@Matt D. i think the reason for this broader trend of FPGA + CPU is because the fundamental compute requirements are evolving rapidly
Hi Jack : How big is your team ?
people want to compute different workloads and they don't know exactly what type of workload it is
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
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
@Max Popp that still remains to be seen. In the current markets of focus a GPU is not really required
@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
Matt D. :-)
Yann Guidon / YGDES But vector code needs even more memory bandwidth :-)
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?
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
Do you have more details about the U500 ?
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
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
in VHDL you have generate statements and even procedures and functions, which are synthesized
multicore, 64-bit, with L2 caches. high speed peripherals: PCIe Gen3, DDR4, GbE
Is there a formal analysis tool for comparing Chisel to the generated Verilog?
if you like using high level design for hardware you will really enjoy Chisel :)
Carol Willing Chisel looks cool and in Scala.
@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?
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
@Jack Kang (Clarification: I meant "do you find".)
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
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 :-)is it this:
@Frank Buss Chisel is based on Scala, so it's a full featured programming langauge
thanks, I will try it
@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.)
@Benjamin Vernoux we haven't decided on U500 package yet. but yes there will be lots of pins
@Nathan Kohagen we write generators in Chisel, then do our verification in Verilog. So we verify the Verilog RTL
lots of great questions! we went quite a bit over :)