Stats

  • Locked Locked
  • Replies 7
  • Subscribers 68
  • Views 14460
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Directed vs Random Testing

FormerMember
FormerMember

Hi

I am writing a paper looking at "myths" in functional verification. By "myth" I mean the types of things which people take as accepted truth even though there may not be much evidence to back them up. So, is the death of directed testing one such myth?

My opinion is:
- random has replaced directed as the preferred test methodology at block level (and if you want a directed test you do that via your random test bench)
- but at chip level there is still a lot of directed mainly for many reasons - the main ones being more legacy of test benches at chip level and legacy of thought (i.e. we must see the chip do this before we ship), you want to see specific integration scenarios (although random + coverage could do that too), and because you are often doing HW + SW coverification where directed is more usual

I'm looking for an active discussion plus references to good articles or papers on this topic please

Thanks

Mike Bartley

Parents
  • Hi Mike,

    It's great to see people thinking about this stuff.

    I agree with your observations, particularly that directed testing is still dominant at system level, but that in theory random + coverage could replace this. I think that not only could it be a replacement but we could see many of the module level benefits which we have seen repeated in system level verification. A particular benefit might be that coverage is inherently more immune to design changes than a directed test, and so more stable verification reuse from previous evolutions of a system might be achievable.

    So the interesting question is why is it not being widely applied? As you suggest software is probably key. Large parts of the system level functionality are implemented in software so a hardware biased view is no longer sufficient.

    The application of Coverage Driven techniques to embedded software/firmware is an area in which I have be working in now for quite some time and as you know the Incisive Software Extensions (ISX) goes a long way to bridging the hardware bias in advanced verification, bringing embedded software firmly under the CDV umbrella.

    I think that there are potentially other problems in bringing CDV to system level, performance too is key. We need to be sure that CDV does not hamper performance improvements made through abstraction and acceleration. This can be achieved through careful, rather than wholesale, reuse, encompassed in a well worked out system level verification methodology.

    Thanks again for raising this topic.

    Giles Hall
Reply
  • Hi Mike,

    It's great to see people thinking about this stuff.

    I agree with your observations, particularly that directed testing is still dominant at system level, but that in theory random + coverage could replace this. I think that not only could it be a replacement but we could see many of the module level benefits which we have seen repeated in system level verification. A particular benefit might be that coverage is inherently more immune to design changes than a directed test, and so more stable verification reuse from previous evolutions of a system might be achievable.

    So the interesting question is why is it not being widely applied? As you suggest software is probably key. Large parts of the system level functionality are implemented in software so a hardware biased view is no longer sufficient.

    The application of Coverage Driven techniques to embedded software/firmware is an area in which I have be working in now for quite some time and as you know the Incisive Software Extensions (ISX) goes a long way to bridging the hardware bias in advanced verification, bringing embedded software firmly under the CDV umbrella.

    I think that there are potentially other problems in bringing CDV to system level, performance too is key. We need to be sure that CDV does not hamper performance improvements made through abstraction and acceleration. This can be achieved through careful, rather than wholesale, reuse, encompassed in a well worked out system level verification methodology.

    Thanks again for raising this topic.

    Giles Hall
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.