• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

RISC-V Micro-Architectural Verification

erek

8=D
2FA
Joined
Dec 19, 2005
Messages
18,278
Pretty cool đŸ€© 😍

“Verification is never complete. The generally accepted approach is that when it is done adequately, the risk is manageable.

“Coverage tells you that you have done something, and it gives you a certain level of confidence,” says Aneja. “But it doesn’t tell you everything. It is a problem if you don’t have it, but it doesn’t guarantee there will not be problems. If you are using simulation, you can generate a lot of coverage reports, and these will give you confidence to say you have stimulated a good part of your design and that coverage proves it, and you have found certain class of bugs. With the complexity, this coverage is not going to be sufficient.”

But processor coverage is unique. “Everybody is talking a different language when they’re talking about coverage,” says Hauck. “It’s pretty easy to go through and touch every one of the 432 million instruction variants that exist. But at that point, it just says you tested your decoder. You didn’t really test anything else in terms of sequences of instructions, combinations that you see, and what might happen to a pipeline. Some people are happy to generate 4 billion instructions, but perhaps you can do better by sitting down with the designer and talk about the pipeline. Identify the things they are really worried about and focus on different combinations of instructions that are more dangerous than others.”

It has to go beyond pure function, as well. “With new custom instructions and items such as vector extensions being introduced in RISC-V, it’s important to know how micro-architectural decisions affect the full SoC and the workloads running on them,” says Andy Meier, principal product marketing manager for Siemens EDA. “Hardware-assisted verification, such as virtual prototype capabilities, emulation, and hardware prototyping are critical components in the overall verification flow. These technologies help to ensure that RISC-V micro-architectural decisions don’t have negative impacts on power and performance tradeoffs.”

When safety is concerned, more rigor is required. “Depending on the level of certification required for the end product, there is a certain level of fault coverage they have to achieve,” says Aneja. “It requires you to inject well-defined faults, which are defined by ISO 26262 for functional safety. You do fault analysis, and then you generate diagnostic coverage. If you insert these faults for critical functions in your design, do you have the safety mechanism built in to take care of those faults, depending on the criticality of those faults?”

When it is impossible to complete verification, heuristics tend to become important. “The overall lesson is you got to keep running real software,” says Hauck. “After you run it for a certain amount of time, everything just seems to work, and it doesn’t seem to break anymore. We can’t quantify what that is and when it is.”

RISC-V’s open-source nature also exposes it to potential security risks. “While transparency allows for community-driven scrutiny, it also means that adversaries have access to the same information,” says Arteris’ Nightingale. “This necessitates robust security verification, ensuring the micro-architecture can withstand diverse attack vectors. Compared to closed architectures, the challenge intensifies, where proprietary designs can maintain secrecy around their security features.”

More dedicated verification tools are required that are tuned for processor verification. “When processors were designed by five different companies, there wasn’t a lot of need for test generators or formal tools around those processors because they were all built internally,” says Davidmann. “But now with RISC-V, there’s definitely a market for architecture analysis, verification, formal around RISC-V ISA and many more. We built a RISC-V DV environment for verification. We’ll see people doing that for performance analysis tools and formal tools over time, but it’s early days.”

Fig. 2 (below) lists methodologies that could be considered when verifying a processor micro-architecture.”

https://semiengineering.com/risc-v-micro-architectural-verification/
 
Back
Top