- 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/
â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/