How far can RISC-V design go with compatibility?

How far can RISC-V design go with compatibility? The answer is not always clear-cut, as the concept of RISC-V is very different from previous open source projects. However, as interest and activity towards RISC-V continue to grow, constructive discussions are underway to address some of the challenges in designing open standard ISA. Mark Himelstein, Chief Technology Officer of RISC-V International, said, "The RISC-V standard is compatible. However, we usually don't use the word 'compatible' because the ultimate goal is to make the application run between implementations that are compatible with the Profile. Compliance is a means of achieving compatibility. ” One of the issues in narrowing down the scope of these two definitions is the historical background. Unlike some open processor projects such as OpenSPARC, it does not involve source code. OpenSPARC provides access to RTL descriptions of Sun Microsystems processors, rather than providing ISA like RISC-V. Roddy Urquhart, Senior Technical Marketing Director at Codasip, said, "The difference between RISC-v and early RISC instruction sets is that it is modular. RISC-V requires the use of basic integer instruction sets such as RV32I or RV64I, and has approved various optional standard extensions. It also defines instruction encoding space for custom instructions. In order to comply with ISA, a necessary condition is to use an appropriate set of basic integers, but if a combination of standard and/or custom extensions is used, ISA complies with RISC-V. ” However, there are still many fragments of this puzzle, and there is still a lot of room for maneuver on how to define it. To comply with the RISC-V standard, you actually only need to implement a very small subset of instructions, "said Rob Aitken, a distinguished architect at Synopsys. Then you can say that your design is RISC-V compatible because it implements the minimum integer instruction set. The whole idea behind it is that an accelerator can be fixed into the system, and then you can have any opcode, etc. The accelerator you want can coexist with the RISC-V minimum instruction block in the instruction set space. All of these are allowed as part of the standard in philosophy. Therefore, in reality, 'compatibility' only means that I have implemented the RISC-V fragment that I said I had implemented, and anything else I have done is within the defined scalability framework, and that's how it is. This is completely different from the previous ISA, where even with any scalability, it was very limited. ” Richard Grisenhwaite, Executive Vice President and Chief Architect of Arm, explains: "Compliance is binary: either 100% compliant or non compliant. If the software you want to run depends on instructions that you haven't built, it won't be able to run on your hardware. If you want the software running on your device to become part of a widely used ecosystem, using instructions that are not available on other hardware is meaningless - this may create problems in encouraging software authors to write non portable software. That's why Arm and many other ISA providers (including open source vendors) are using a range of name extensions to effectively standardize architecture. If you follow these extensions and specifications, compliance is not a problem, but it does not give you the flexibility that open source expects. ” Understanding compliance in open standard ISA design environments remains challenging.

Simon Davidmann, CEO of Imperas Software, said, "To get this job done correctly, a lot of resources are needed." "Compliance is about control. If you want to be compatible with definitions, someone must provide the ability to demonstrate and enforce compliance. What companies like Arm do is to control it in many different ways, just like all ISA did in the past. They said, 'This is our definition.'. You can't take it out of this envelope. On Arm, you cannot add instructions, change decoding, or add registers because if you do anything, it is not 'Arm' and their permission does not allow you to do so. ”Even Google, Samsung, and other architecture licensees are not legally allowed to prevent it from becoming an Arm. ” However, Arm allows architecture licensees to make slight changes to RTL, but does not allow changes to the source code. David Mann said, 'You can add an additional stage in the pipeline, or you can implement it in a different way, which Apple did in M1 and M2.'. ”But how can they prove it's still an arm? "How is it compatible with Arm? Arm provides important technology, depending on what you authorize and to what extent you are allowed to manipulate it. For example, if someone only authorizes a small kernel and is not allowed to change it, they will only receive some very simple compatibility tests to check it because they are not allowed to do anything to change it. They can't really change the re education through labor system, so there's nothing they can do. They can synthesize it, they can target different things and get different gates, but they don't allow changing RTL, while Arm architecture licensees like Apple, Google, Samsung, or MediaTek can change pipeline stages. They can do what they like, in fact, some people can start from scratch. They can say, 'We will accept your file and build it in the way we like.'. How can we prove that it is compatible? For architecture licensees, as part of their millions of dollars, they have gained a wealth of compatibility technologies, including references, testing, and frameworks. Then they can check to see if it's still an arm, and they must fix it. ” In addition, although users of embedded processors often compile their software from source code, the rich operating systems and applications running on them are delivered in the form of binary files. Urquhart pointed out that this requires a consistent combination of basic integer sets and optional standard extensions. RISC-V International has standardized it by defining configuration files such as RVA22U64, which specify mandatory combinations of standard extensions. Therefore, in some contexts, it is important to comply with the profile in addition to following ISA. For example, if the design is implemented as RTL, can it be validated based on an accurate model of the instructions? This will require the model to include basic integer instructions, selected standard extensions, and custom instructions. ”

For example, Codasip Studio can generate a UVM environment to perform this operation. However, from this perspective, the regulatory compliance process has an impact on the design or design process. According to Himelstein from RISC-V International, the first "configuration file" was approved this year, which includes a generation of extensions consisting of instruction states and behaviors that can work together. Expansion is either mandatory or optional. The implementation that is compatible with the profile must implement all necessary extensions. The configuration file provides a single goal for the entire community's operating system and toolchain. ” If there are non compliant issues, the supplier will issue a errata and recovery plan. Himelstein said, 'If this is intentional and allows for custom changes, then suppliers cannot advertise their products as RISC-V profile compatible.'. ” Every architecture has this issue. Himelstein pointed out, "We have a basic set of tests that can be validated through simulators to obtain the best results. However, this depends on the supplier proving that they have done enough DV, system testing, software testing, etc. We are not a certification body. There needs to be a viable software economy to drive everyone to be compatible with profiles, so that software vendors can provide a cross implementation version for each operating system type. We are a community, a constantly improving organization. We have been working hard to improve the simulator and testing. ” Fragmentation risk Fragmentation has always been a concern in the software field. Although open hardware standards do not necessarily require support from open source compilers, both the LLVM community and GCC community are working hard to support RISC-V, and deviating from hardware standards can have an impact on open source implementations. Catherine Moore, Director of Software Engineering at Siemens Digital Industrial Software, explained that in the RISC-V field, some of the standards that took a long time to obtain approval were vector extensions of the RISC-V standard. Many hardware vendors did need this extension before the standard was approved, so many hardware vendors left and implemented what they thought was the standard, and implemented their own standard versions, and so on. So now these things are hard coded into their standard versions, which deviates from the final approved standard. Therefore, they have to develop compilation tools to support their standard derived products, of course, what we see is fragmentation This in turn creates opportunities for organizations that provide customized software services for open-source compiler tools. Moore said, "When these hardware standards become fragmented, this is a huge support opportunity because most people who build open source components want to submit and accept these components into the open source community they are building. However, for example, GCC will not accept any submissions that deviate from the standards, so vendors who implement vector extensions in RISC-V at once need to support it outside of the community support provided by GCC or LLVM. ” The consequences of fragmentation are significant, with the result that the cost of supporting it will be higher, as implementing different standard parts in the design is outside the community. Nevertheless, RISC-V allows for custom instruction sets. The RISC-V standard has an extension that allows suppliers to create their own customized instructions, "Moore said. Fragmentation is separate from this because there is a standard for how to create separate instructions. There is a code that marks things as independent and proprietary. These things should be considered part of this standard. Implementing extensions that are different from the standard approval method is where you encounter trouble, at least in the software world sound the alarm In order to make the RISC-V design compatible with another ISA, extensive verification compatibility testing is required. Imperas' Davidmann stated, 'RISC-V does not advocate for compliance like Arm does.'. They don't have the resources to provide compatibility testing. What they do is voluntary work, creating open community testing, which is basically very simple compatibility. I don't think there is currently a very good compatibility suite. In our first job, when our model and reference simulator were in the compatibility group, we created some tests and created a reference to try to help solve this problem, but there were no available resources. In a commercial company, you have to think that Intel made a lot of money from chips, so it can invest a lot of money in verifying compatibility. Arm made a lot of money by licensing cores, so these cores have a huge source of income, and what they did was invest in their ecosystem, many of which are... It's in terms of compatibility. The RISC-V ecosystem has no funding. Everyone is an independent individual. What they do in compatibility is, 'Here are some simple tests that you must run.' When you finish running them, send us your data and we will allow you to use RISC-V compatible badges. ’But this is not a commercially reasonable insurance policy. ” In addition, compliance is a necessary but insufficient component of verification. Codasip's Urquhart said, "Microarchitecture design may have various errors unrelated to ISA or configuration file compliance. ”For example, there may be competition conditions or interrupt or cache interface issues. Considering that processor design has a very large state space, RTL validation is much more complex than hard connected accelerator blocks. Usually, we combine multiple methods to discover vulnerabilities, including direct testing, constrained random methods, and formal validation

Synopsys' Aitken also believes that compliance testing is tricky. Whether it is an open ISA or a closed ISA, it is the same. In fact, compliance with customizable or extensible objects has become more challenging. What do you mean by saying that? If you have an illegal opcode in Arm or x86, it will only say, 'Illegal instruction', that's all. But in RISC-V design, depending on what the opcode is, it may actually be illegal opcode. Maybe someone else added it. Do they have to tell anyone? There may be many gray areas in this field because it can be very chaotic, so people avoid the entire problem by choosing well-defined subsets. ” Compared to extensible ISA, the difference between compliance and validation in fixed ISA is slightly clearer. Can this thing execute the instructions it should execute? "This question is easy to answer. ”Aitken said. Does it have any other functions it claims to have? Has it done so in a compliant manner? There is a gray area between where it ends and where some implementation error begins, partly due to the difference between ISA and architecture or microarchitecture and the specific implementation of that microarchitecture. If there is only one, where is the problem? As a user, you may not know. Even as a developer of a product, you may not be able to determine which part of this continuum your problem lies within. If it is' here 'and our interpretation of the norms is incorrect, then it is a compliance issue. If we interpret the specification correctly but implement it incorrectly, it may be an architecture error, microarchitecture error, or implementation error, depending on what you actually did because you implemented it incorrectly. ” How do developers determine? You don't know, "he said. You only know that in the end, you have to identify the problem and solve it. However, the accurate description of what was disrupted and how we described it may not be clear. Therefore, this will come down to a pragmatic viewpoint, which is' it didn't work before, it works now. Check the box. 'Why wasn't it successful before?' Hmm, that's quite complicated. ” Warning Davidman said that ultimately, compatibility testing in RISC-V is not validation, which means that when they are completed, they may only cover 10% or 20% of the actual functionality in the specification. The real trouble with RISC-V is that customers can make too many choices in implementation, making it difficult to actually write tests that are applicable to all of these different designs. For an industry attempting to build software defined chips, the freedom they offer on RISC-V is great, but this freedom means it's a complete nightmare in terms of compatibility. The RISC-V industry has not truly understood the complexity of this compatibility challenge, and they have absolutely not invested resources

Arm's Grisenhwaite added, "Compliance is indeed a part of validation, but it is important to have precise and comprehensive specifications that explain what needs to be built to meet the requirements. When it comes to personal instructions, this is straightforward; for other projects, it is more complex, and if the software depends on the behavior involved, then minor non-compliance may be as big a problem as obvious failure. It is important to remember that compliance is a subset of validation, which involves more closely searching for implementation specific issues, including performance exceptions. Validation is clearly the core of the design process - usually the most time-consuming part - and validation methods become trustworthy and resilient because they have already been implemented. Millions of designs have been deployed across a wide user ecosystem The scalable architecture makes it more difficult. If you want a scalable ISA, it becomes even more challenging, "Davidmann concluded. There is a company with funds to invest in this project. Community investment does not work for hobbyists. When Arm encountered problems on Linux, they founded Linaro, which is an annual investment of $30 million to $40 million. This cannot be a hobby club. There must be full-time engineers. For RISC-V, you may need a full-time team of 20 people to build compatibility technology. It includes referencing, validation capabilities, and testing. The impact of all of this is that if you want to authorize a processor, you need to know two things. Does it meet the standards, so everything can work properly? Are there any other insects inside? These are the questions that every IP supplier will be asked by their customers, and RISC-V International is not concerned about compliance issues that should be addressed today. They said it was written. Their behavior does not indicate that they are concerned about it

Semiconductor Engineering - Deep Insights For Chip Engineers (semiengineering.com)

EE Times - Connecting The Global Electronics Community

www.semiwiki.com

News for compound semiconductors, gallium nitride, gallium arsenide, indium phosphide, silicon carbide and the LED industry (semiconductor-today.com)