Is open source silicon the next logical step after the proprietary IP licensing model? To paraphrase Sir Robin Saxby, founding CEO of ARM, at the 2013 Global Semiconductor Alliance Entrepreneurship Conference in London: “Don’t try and build the next ARM; build the company that will replace ARM.”
注：Sir Robin Saxby是ARM的首位CEO，也是IP商业授权模式的开创者。
2018年10月18日, RISC-V Day Tokyo将在Keio University举办，演讲征集即将结束。
在YC网站上，有人贴出了InCore的创始人和CEO G S Madhusudan对于Shakti的一些个人看法:
As the lead architect of Shakti and the guy who helped kick-start the project, I figure I am owed my 2 cents !
- We never positioned it as an ARM killer ! That was the imagination of the reporter who wrote the article.
- Shakti is not a state only project. Parts of Shakti are funded by the govt, these relate to cores and SoCs needed by the Govt. The defense and strategic sector procurement is huge, runs in the 10s of billions of USD.There is significant funding in terms of manpower, tools and free foundry shuttles provided by the private sector. In fact Shakti has more traction with the private sector than the govt sector in terms of immediate deployments.
- The CPU eco-system including ARM’s is a bit sclerotic. It is not the lic cost that is the problem, it is the inherent lack of flexibility in the model.
- Shakti is not only a CPU. Other components include a new interconnect based on SRIO, GenZ with our extensions accompanied by open source silicon, a new NVMe+ based storage standard again based on open source SSD controller silicon (using Shakti cores of course), open source Rust based MK OS for supporting tagged ISAs for secure Shakti variants, fault tolerant variants for aerospace and ADAS applications, ML/AI accelerators based on our AI research (we are one of the top RL ML labs around). 5 the Shakti program will also deliver a whole host of IPs including the smaller trivial ones and also as needed bigger blocks like SRIO, PCIe and DDR4. All open source of course.
- We are also doing our own 10G and 25G PHYs
- A few startups will come out of this but that can wait till we have a good open source base.
- The standard cores coming out of IIT will be production grade and not research chips.
And building a processor is still tough these days. Try building a 16 core, quad wide server monster with 4 DDR4 channels, 4x25G I/O ports, 2 ports for multi-socket support. All connected via a power optimized mesh fabric. Of course you have to develop the on-chip and off-chip cache coherency stuff too ! 8. And yes we are in talks with AMD for using the EPYC socket. But don’t think they will bite.
Just ignore the India bit and look at what Shakti aims to achieve, then you will get a better picture. I have no idea how successful we will be and I frankly do not care. What we will achieve (and have to some extent already) is - create a critical mass of CPU architects in India - create a concept to fab eco-system ind India for designing any class of CPUs - add a good dose of practical CPU design knowhow into the engineering curriculum - become one of the top 5 CPU arch labs around
Shakti is already going into production. The first design is actually in the control system of an experimental civilian nuclear reactor. IIT is within the fallout zone so you can be sure we will get the design right. If you want any further info, mail me. My email is on the Shakti site. G S Madhusudan
Very different things are in Indian semiconductor industry in comparison to China:
Availability of professionals
- India: makes tons of electronics engineers and semi specialists, but very very few of them find employment in the country.
- China: there is a somewhat ok amount of undergraduate cadres, but for anything above this, you have to attract people from abroad. And yes, Chinese fabless were hiring from abroad since the very beginning. In fact, people who make SoCs at Allwinner, Rockchip and etc are around 50% undergrad and 50% masters level people. In their early days they were eager to hire random college grads and teach them verilog on site.
- India: a research program, all work in the past few decades was about delivering some kind of proof of concept level “national chip”
- China: make money quick - 9 out of 10 Chinese fabless start with bog down standard, off the shelf “solutions” from ARM, and add some flavour: here you have 4 channel camera controller, here eDP on chip, and here 10G Ethernet for pennies.
- India: with all respect, the truth is there are none. And from many people I hear the same criticism - even if the 10th in a row state backed effort to make the “national chip” will succeed, there will be no chances of it ever sustaining it with microscopic domestic market as demanded by political mandate.
- China: foreign markets - even 15 years ago, Chinese fabless well understood that their value proposition is actually lesser in domestic market than for the export manufacturing. Most Chinese buying a PC 20 years ago were not deliberating whether their PC has Sigmatel audio codec or some cheaper domestic analogue, but for somebody making stuff for export, every penny saved on expensive imported chip mattered a lot. Even today, the pattern holds: Chines domestic market smartphone models have high-end Qualcomm or Samsung flagship class chips in their majority, and for export they do Mediatek, Allwinner, and Spreadtrum
Pierre G.在RISC-V ISA Dev提出为什么RISC_V需要要MPIE Pierre G.说理解SPIE & UPIE的作用，但是risc-v进入”machine mode”模式没法再通过中断进入更低级别的 的特权模式，那为什么需要MPIE?
I have a naive question : why do we need MPIE ? I understand how it works : when an interrupt is taken, MPIE captures the value of MIE, and at the end on the interrupt routine, MRET will copy back MPIE within MIE.
But, in anycase MPIE is necessarily equals to 1 :
- if an interrupt is taken, this means that MIE was enabled.
- at the time the interrupt occurs, MIE is copied into MPIE; so is 1.
- MIE is written to 0 After the first interrupt will be serviced (execution of MRET), MPIE still holds 1, and MIE is restored using MPIE=1.
I understand the role of SPIE & UPIE because S&U mode can be interrupted to go into machine mode, but I do not understand the need of MIPE since machine mode cannot be interrupted and switch to lower priority mode.
Allen Baum给出了原因，MPIE是为了防止或者允许重入, Allen Baum的具体解释是:
Obviously, M-mode only implementations are allowed, so you need to be able to take interrupts from m-mode to m-mode. When you first enter M-mode, interrupts are disabled, and you need to explicitly save state and reenable interrupts in order to take another interrupt (unless M-mode knows there is no state to save, but that only works once…).
Taking exceptions (synchronous exceptions) is nastier - your handler M-mode code should be written so that it doesn’t take an exception, or at least not before its had time to save a few CSRs somewhere (e.g. saving the few csrs better not trao!). Primarily, that means access to the physical address of the handler should guaranteed, and access to the save area should be guaranteed. Having said that, it is still the case that an NMI could come in - that’s basically fatal in this scenario, and should be confined to HW error conditions that are fatal anyway.
Getting back to the original question: the reason you need MPIE is to prevent and allow reentrance.
Jacob Bachmeyer对Allen Baum的答案做了进一步的诠释， 对于 “Taking exceptions (synchronous exceptions)…and access to the save area should be guaranteed.”， Jacob Bachmeyer补充说
This was hashed out previously in the “nested trap” discussions: all trap handlers must have a context-save area that can be accessed without incurring a horizontal trap. This issue also hits the supervisor. It is more than just the CSRs: the entire general register file must be saved.
对于”Having said that, … that are fatal anyway”, Jacob Bachmeyer补充说
Does this mean that MPIE in the NMI handler is effectively the “recoverable NMI” flag? If MPIE is set when the NMI handler is entered, nothing has been lost (since the monitor was prepared for an interrupt) and the monitor can resume execution after handling the NMI, probably after software-delegating the NMI to a “machine check” handler previously registered by the supervisor using some to-be-defined SBI call. If MPIE is clear when the NMI handler is entered, the NMI occurred while entering the monitor trap handler and the resume point has been destroyed; the only path forwards is to reset.
High-reliability system can avoid these problems by placing the monitor entry point and context save areas in internal (multi-port) SRAM, with extensive ECC on that SRAM and dedicated ECC scrubbing hardware with its own SRAM port. (If that fails, the main registers probably cannot be trusted to hold values either and the system will crash no matter what.)
Link: RISC-V ISA Dev
NXP 和 Dover Microsystems 在2018年7月23日发表联合声明。NXP将在其处理器中使用 Dover Microsystems 的 CoreGuard 技术来巩固其安全处理器。 面对物联网和端计算快速增长的需求，NXP将致力于提供全面的安全保护来应对从物理层、逻辑层和网络层的攻击。 Dover Microsystems 的 CoreGuard 技术提供了一种全新的方式来保护处理器。 通过使用预先确立的规则，CoreGuard 实时检测处理器上运行的每一条指令，在恶意指令执行的第一时间将其阻截。
编辑注：Dover Microsystems 是美国MIT Draper实验室孵化的初创企业。 CoreGuard实际上来源于美国DARPA的CRASH项目，旨在研究创新性的能从根本上保证计算安全的新技术。 Draper实验室提出了使用generic tag来标注计算系统中的数据和指令，并通过tag协处理器来实时监测指令运行的安全性。 具体的信息，可参见：
Stacey Higginbotham在IEEE Specturm杂志八月刊发表了文章”The Rise of RISC”。
This technology lowers the cost of creating custom chips, which means more and more companies may elect to build their own. As for the existing players, I don’t think RISC-V represents a bigger threat to Intel than does the slow fade of Moore’s Law and former customers deciding to build their own dedicated silicon. And I don’t think Arm will necessarily lose licensing fees to RISC-V right away—but the technology could bring on a wave of competitive silicon that hurts incumbents in the long run.
Dolphin发布了最新的IDE: SmartVison™ 2.4.0，对RISC-V的支持更加成熟和完善。
- Support of the “F” instruction set extension for single precision floating point registers and operations
- New stack-unwinding tool in the debug toolbox to speed-up application program debug by giving access to program execution stack frames
- Several new pre-defined MCU subsystems based on the RV32 Tornado both in simulation and emulation for reducing application development time and for easily use RISC-V peripherals
- FreeRTOS support for RV32 Tornado to debug efficiently RTOS-based applications
- New intuitive wizard for the creation of RISC-V subsystem projects and the generation of RTL configuration files
欢迎关注微信公众号CNRV，接收最新最时尚的RISC-V讯日, RISC-V Day Tokyo将在Keio University举办，演讲征集已经开始。注册网站 息！
本作品采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。